Comment by jcgl
Comment by jcgl 2 days ago
Unfortunately it's most ActivityPub-oriented, right? Which means no name portability. That's a major shortcoming compared to an AT protocol-based thing like Tangled appears to be.
Comment by jcgl 2 days ago
Unfortunately it's most ActivityPub-oriented, right? Which means no name portability. That's a major shortcoming compared to an AT protocol-based thing like Tangled appears to be.
First of all, non-standard extensions to federated protocols have a pretty rough history. Even when an extension reaches median adoption (rare, I assert), the long-tail adoption is dismal. For something as fundamental as
Second of all, how could this just be an implementation-specific extension? The failure mode (of a client not supporting the extension) would be outright broken. To have name portability, the client needs a two-step to first discover the name's server before then connecting to that server. Whereas now (afaiu), the server is already identified by the name. That's a fundamental change in what identity means at the protocol level.
I'd love to be corrected by someone more intimately familiar with ActivityPub. But until it has mandatory (and mass-adopted) support for something vaguely like SMTP's MX records or whatever the equivalent for ATProto is, name portability is a distant dream.
I'm not intimately familiar with the spec, so don't take my word as gospel, but as I understand it, current implementations already do name discovery. It's just that every implementation hardcodes the server name. IIRC some people have applied some kludge where they put a .well-known document on their own server to point to their instance's account, but it's still pretty spotty without that server being actively aware of that identifier. But (again, if I'm understanding correctly) servers could be updated/written to support that properly.
Not to split hairs, but that sounds more like plain hackery rather than proper extension. Let alone a viable future. I don't doubt what you say that it's possible in the most technical sense of possibility. But actually possible, in this world where we live? No, doesn't seem like it.
I might be overlooking something, but if Mastodon were to decide to add an input field to your settings page where you could enter your domain, along with instructions on what static file to upload where (ie in .well-known), I wouldn't be surprised if the rest of the ecosystem were to follow.
I don't tend to believe in cryptokey-first protocols like Nostr, where your identity is tightly coupled to a keypair. Human identity doesn't work like that at all, and keypairs as the basis of identity will never be suitable for use by the masses.
Human-readable names are far more suitable as a handle for identity as humans think of it. And DNS names are an okay-ish implementation of that.
I think that a decentralized protocol that provides name portability based on the DNS is a far better protocol than one that relies on keypairs.
Not really. It's very open for everyone to participate. Further, Bluesky has been working on standardizing AT at the IETF [0][1]. They have also made a patent non-agression pledge: https://bsky.social/about/blog/10-01-2025-patent-pledge
In short, they're actively working on making AT as neutral as possible.
[0]: https://docs.bsky.app/blog/taking-at-to-ietf
[1]: https://datatracker.ietf.org/doc/bofreq-newbold-authenticate...
I don't think it's relevant to this specific instance, but AFAIK ActivityPub doesn't inherently prevent name portability. It's just that almost all implementations currently don't allow it (and I wouldn't expect Forgejo's either).
Of course, the practical downside of Tangled is also that it only has network effects within the ATmosphere, i.e. you still can't reach GitHub users.