No, I think you might be conflating my implementation with what the Lemmy/Fediverse/ActivityPub does. I am not using any of those. Unlike those, in my LimeReader, there’s no real concept of “accounts” or registration. The “login” phase is mostly used to help users easily generate the public private key pairs. But they don’t necessarily have to do it on my site. Any valid ECDSA p-384 key pair will work.
I am using ECDSA P-384 for the keys and signing. Browsers come with the CryptoSubtle library which does this natively, so I am able to build it all with pure vanilla javascript without frameworks:
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
The client (browser) creates the public private key pair. The private key pair never leaves the client device. The client uses the private key to sign the records (data such as user metadata, comments, posts, votes etc). These signed records get sent along with the public key and signature to multiple servers hosted by multiple people and then fetched by multiple other clients from these servers. The servers (if they want but highly encouraged) verify the signature of the records using the public key. If verified, then it stores that record as “belonging” to that public key. The public key is basically the user’s identity. It’s also unique. So one public key is one account only. When other clients fetch these signed records, they also verify the signature.
Behind the scenes, there are no “real” accounts on servers. There are only records which have been sent by the public key and been verified. Using these records, the clients create the metadata of accounts, communities etc.
The API will be only 2 endpoints - /search and /create.
The /create accepts the signed records of various types. These are the types of records which can be created for my site which I also think should cover most similar sites: user, community, text, reaction, hide, bookmark, pin, award, view, delete, follow, report, collapse, media
The /search accepts the filters which are enough to build the feed of a link aggregator like website.
The signature of each record is unique due to the benefit of ECDSA signatures. So, the signature also becomes the “id” of your record. The replies to your comment all reference this “id” i.e. the “signature” of the comment they are replying to. These replies get sent to multiple servers (whichever ones the client has configured). Unlike the Fediverse, in my way, the servers don’t talk to each other. The client talks to multiple servers and sends its signed records to them.
I will have a more detailed write up in the coming days. I am having to have all this work as seamlessly as possible so that to a non-techy person, they shouldn’t have to understand such complexity. On the front end, it will look like a simply link aggregation site.