so, this is a bit of an abstract mathematical post.
I think that a fediverse service consists mostly of three parts: identity provider, data hoster, and feed provider.
The data hoster is the machine that hosts the posts and comments and upvote/downvote stats. The feed provider is the service which gives you a nice, scrollable overview over new content for you. This is today the same system that provides the data, but it could be separated, such as having a custom “search engine” that gives you content, that you use independently of where the data is stored.
The identity provider basically only makes a proof that “you are you” : you give it your login credentials and it gives you a kind of token that authenticates (proves your identity) to other services. like, i’m on discuss.tchncs.de, but i can post to lemmy.world. this is because the discuss.tchncs.de server says to lemmy.world that i indeed have this account on this server. so they prove my identity in a way.
What i argue now is that such an identity providing server is not technically necessary. You could use something like an ~/.ssh/id_rsa file that you generate on your own computer and use that public key to identify yourself on the fediverse. I don’t think that this approach has any inherent advantages over how things are being done today, but it could be done that way and that in itself is fascinating.
:D
You must log in or # to comment.
Identity based on a pubic key is already not theoretical, it is supported by services that implement FEP-ef61.
I am not sure whether it makes sense to separate data hosting and feed generation, this will probably require a specific network architecture, similar to Bluesky, which tends to be centralized.
The big problem with improving how this stuff works on the fediverse is that you want to stay compatible with other software and instances running older versions of your software. In general, ActivityPub projects expect the id of an actor to be dereferenceable. They expect it to point to a valid JSON-LD document describing the actor which they can request. If you break this expected contract by using a local file as your identity, or even just a non-https URI like
did:, you’re going to lose intercompatibility with other instances that don’t handle that.
Also, regarding your description of the three parts, I think you’re misunderstanding something that I see people misunderstand often.
The identity provider basically only makes a proof that “you are you” : you give it your login credentials and it gives you a kind of token that authenticates (proves your identity) to other services. like, i’m on discuss.tchncs.de, but i can post to lemmy.world. this is because the discuss.tchncs.de server says to lemmy.world that i indeed have this account on this server. so they prove my identity in a way.
So, I might be wrong here, but I interpret you as saying basically that you’re authoring posts on lemmy.world with your account provided by discuss.tchncs.de. That’s not really how this works. Your data hoster is the instance you have your account on, not the one the community is on. Your instance just shares the posts you make on it with the community, but all it receives is a copy. The canonical version is on your instance, discuss.tchncs.de.
Again, data hoster and identity provider are currently the same thing. The fediverse is just a bunch of interconnected silos, you do things within your own instance and then other instances receive a copy of the thing you did. You never author things directly on another instance than your own.
The token stuff there sounds like SSO (single sign on), but it doesn’t look like either of those instances support that. So not sure what you were referring to there. The public key to verify the signature maybe? That’s more meant to ensure that the object is actually authored by you iirc though.
Very interesting!
I agree with your point that a user account without a canonical URL to send messages to could not have an inbox, and therefore never get DMs or notifications if somebody commented on their post.
I had not thought of that before but it seems obvious to me in retrospect. Obviously, to receive messages, you need some kind of machine-address, where these messages will be sent to. And that’s what this is for:
They expect it to point to a valid JSON-LD document describing the actor which they can request.
Because it describes the inbox address.
Your data hoster is the instance you have your account on, not the one the community is on. Your instance just shares the posts you make on it with the community, but all it receives is a copy. The canonical version is on your instance, discuss.tchncs.de.
That’s truly fascinating knowledge, thank you. It makes sense because in the ActivityPub protocol, each user has an outbox, and published posts go there. So of course, other communities simply reference that instead of actually holding the post.
This means, then, that communities aren’t actually so much lists of posts, but lists of references to posts, i.e. when i post to /c/a@lemmy.world, that community simply gets notified about the canonical link to my post, which actually resides in my outbox on this server. Thanks for making me think about all of this!
BlueSky uses AT Protocol which is similar to how you break things down: https://en.wikipedia.org/wiki/AT_Protocol
That is a lot like AT Protocol.
There’s pros and cons to every architecture. Which pros seem important and which cons you can put up with depend on your values and priorities.
