Interesting new DID method: "did:self"
Technical Discussion
1
Posts
1
Posters
3
Views
-
One consequence of trying to separate identity hosting from the other components of the system is that it makes the other components harder to bootstrap. If I run just one component of my instance in isolation, how can I authenticate to it in order to configure/manage/test it, if I don't have an identity that I can use?
The answer might be to use a did:self identifier. The flow would look something like- Management CLI tool generates a JWT describing a
did:selfidentifier, and stores the private key locally - Admin uses
scpor something to copy this JWT to the right place on the server - The server now has the ID's public key and so the CLI tool can prove that it "owns" the identifier
Which seems like a reasonable fix for the classic problem of "how do you create the first user", and also a useful fallback for when the system is too badly borked to be able to look up real identities.
Another interesting property ofdid:selfis that seems to be possible to add extra metadata, such as a human-readable name, to the ID, by using standard JWT claims - without needing the data to appear in the DID document.
Of course these identities will only be visible to the server they're copied to, not to the whole network, but that shouldn't be a major problem.
(Cue the peanut gallery, with their suggestions of "it's easy, just do so-and-so", because everything looks easy when you take it out of context...)
#ActivityPubDev #FediDev - Management CLI tool generates a JWT describing a
Gli ultimi otto messaggi ricevuti dalla Federazione
-
The answer is vigorous code review. Anything that connects to an API, anything that is federated, shared, made free, or made at all should be reviewed for intent, for mistakes, for data integrity, for documentation and for competence. I don't care who or what creates it. Without code review, it's so untrustworthy that it poisons the well.
-
@stegodon What can I do while staying compatible with HTTP/1.1? https://github.com/astro/buzzrelay/blob/main/src/send.rs#L37
-
TIL: FediBuzz sends both :authority AND Host headers in HTTP/2 requests. old nginx rejects this as "duplicate". Both are kinda wrong - HTTP/2 replaced Host with :authority, but nginx shouldn't reject matching values. Fixed by upgrading nginx to 1.29+
-
@stegodon Sounds similar to my issue https://github.com/astro/buzzrelay/issues/132
>hyper/reqwest
I assume it's one their side (because Stegodon is written in Go)?
-
@smallcircles @fedicat @reiver
The question is: Do people even know what they are doing? Can they guarantee and ensure reliability, security, data protection and smooth operation in a network?
-
@reiver Even if you want to help I would avoid doing anything specific to whatever practice happens to be the fad this week. Clear documentation, example code, conformance tests, etc, all benefit every developer.
-
@reiver @josemurilo I voted Yes! But let me explain my point of view.
I have been programming for over 15 years… but I am also an #AuDHD who was diagnosed less than five years ago. Also I've been involved in an accident that affected my whole left arm. I can still type with it, but too much of it results in long periods of pain.
Also, besides working with computers, I am a full-time nurse student.
There are so many things I want to code, but I simply don't have the time or energy to do it. Telling an AI to create a simple loop, a class or even a module boilerplate really helps me a lot!
So, please, do help me!
-
🔧 Devlog: FediBuzz relay returned 400 errors. Root cause: nginx 1.18 + HTTP/2 + hyper/reqwest sent duplicate Host/:authority headers. Fixed by upgrading to nginx 1.29.4 which handles HTTP/2 headers correctly (fix from Aug 2025). #fediverse #activitypub #devlog
