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
@gandalf_der_12te@discuss.tchncs.de haha i think that was a typo i meant normal dereferencing (which is admittedly already an annoying term of Semantic Web art that I only use to help people bashing their head against these specs for the first time). plainly speaking, a “web-based DID” (any of the did:web successors linked above) gives you rules for translating, e.g.,
did:webvh:bumblefudge.com:1234intohttps://bumblefudge.com/1234/.well-known/did.json– you can just make that second string into theidproperty of an actor, and put a normal AP actor object in the file you get back at that URL and for the AP world (that doesn’t have to know or care what a DID is) that’s just… an Actor. The controller of that Actor can use the the first string in DID-based system, if those ever exist at scale. To date, the only pertinent place you can use a DID but not an Actor ID is in… an At Protocol URI, i.e.at://did:webvh:1234/lexicon/recordkey(sidenote, yes, those colons are invalid, dropping thedid:and inverting the rest of the authority to1234:didwebvhwould be a more conformant URI)Anyways, hope that’s helpful to whatever research and/or design you’re doing, I’ve probably ranted enough for one thread :sweat_smile: