Comment on theoretical considerations on identity management
Pamasich@kbin.earth 1 week ago
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.
gandalf_der_12te@discuss.tchncs.de 1 week ago
Very interesting!
I agree with your point that a user accou t without a canonical URL to send messages to could nor 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:
Because it describes the inbox address.
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!