this post was submitted on 02 Feb 2026
25 points (96.3% liked)

Fediverse

40438 readers
615 users here now

A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, Mbin, etc).

If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!

Rules

Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration)

founded 2 years ago
MODERATORS
ruud@lemmy.world
Xylinna@lemmy.world
MrCenny@lemmy.world
TragicNotCute@lemmy.world
automodbeta@lemmy.world
woelkchen@lemmy.world
25
theoretical considerations on identity management (discuss.tchncs.de)
submitted 2 weeks ago by gandalf_der_12te@discuss.tchncs.de to c/fediverse@lemmy.world
15 comments fedilink hide all child comments
 

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 are viewing a single comment's thread
view the rest of the comments
[–] bumblefudge@activitypub.space 2 points 2 weeks ago* (last edited 2 weeks ago) (2 children)

See also FEP-e3e9 on DID-like redereferencing from an HTTP server of actor objects-that-are-also-DID-docs

using a did:... as an actor.id prop is a little spicy and isn't exactly backwards compatible with the entirely HTTPS-based fediverse, BUT all web-based did methods in their respective ways (did:web, did:webvh, did:webplus, and even did:plc if you squint a little and hardcode the discovery path to a document cache like plc.directory or a custom resolver like pdsls.dev) let you express a DID not just as a did string but also as a normal URL that dereferences to a DID document that is also a conformant/valid Actor object. if the server does con-neg and returns the actor object as JSON-LD (or debatably even if it ignores con-neg and just already serves a JSON-LD did doc without the appropriate content-type header) then... you just dereferenced an actor conformantly even though what you got back was a "DID Document" in addition to being an actor object.

[–] gandalf_der_12te@discuss.tchncs.de 1 points 2 weeks ago (1 children)

redereferencing

omg, what a word :o :D

but in general, yes you're right, adding DIDs to the game is interesting, and making the DIDs also valid URLs is even more interesting. I have been thinking about a similar DID mechanism, where the DIDs are not URLs but public cryptographic keys. this way, each human could prove that many accounts are all signed with the same key, and therefore belong to the same human.

Edit: oh wait i think the official(?) DID specification (here: https://www.w3.org/TR/did-1.0/) actually already expresses this concept:

Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Services enable trusted interactions associated with the DID subject. A DID might provide the means to return the DID subject itself, if the DID subject is an information resource such as a data model.

[–] bumblefudge@activitypub.space 2 points 2 weeks ago

@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:1234 into https://bumblefudge.com/1234/.well-known/did.json -- you can just make that second string into the id property 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 the did:and inverting the rest of the authority to 1234:didwebvh would 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: