- From: Bumblefudge <bumblefudge@learningproof.xyz>
- Date: Mon, 28 Apr 2025 21:20:55 +0200
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Johannes Ernst <johannes.ernst@dazzlelabs.net>, public-swicg@w3.org
- Message-ID: <CAP8tQw1AFE2h5VSfp9s3ZCZDwzovQhWbWKpWMGF9hGhY4ezAbA@mail.gmail.com>
PRs are always welcome if you'd like to add a "unforeseen DNS change" use case to the reference document that the Data Portability Task Force has been using to organize its work: https://codeberg.org/fediverse/fep/src/branch/main/fep/73cd/fep-73cd.md Dmitri and I wrote a FEP for how users who control a domain and are willing to set up a micro HTTP service at that domain (a "$5 hetzner" or turnkey YuHost/Vercel/etc type service) could achieve domain-independence and server-swappability, including unforeseen DNS changes on the part of the [swappable] service providers hosting their endpoints and data: https://codeberg.org/fediverse/fep/src/branch/main/fep/e3e9/fep-e3e9.md I would also note that there has been a lot of debate in the AT Protocol dev community recently about bluesky using "handles" (susceptible to both user-originated changes and unforeseen DNS changes) in their thus-fragile "permalinks" when they could (and IMHO should) just use DIDs in their permalinks, as they do in their internal at://... links. Note that in the ATProto design, DIDs remain unchanged across all kinds of updates (including service-provider rotations and DNS changes), and remain verifiable over time since that long-lived identifier is a hash of the initial state of the actor-object equivalent: https://bsky.app/profile/shreyanjain.net/post/3lnt24dmvs22x Note that while I generally advise not discussing ATProto design in detail on the list due to IP safety issues, none of the above is original to ATProto or unique to its usage of DIDs; prior art is already well-documented in W3C WG history, and described in detail in specs that predate bluesky and that are under W3C and/or Linux Foundation IP Umbrellas. On Mon, Apr 28, 2025 at 8:18 PM Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > po 28. 4. 2025 v 20:05 odesílatel Johannes Ernst < > johannes.ernst@dazzlelabs.net> napsal: > >> As we all know, threads.net has moved to threads.com. My understanding >> is that in their current plan: >> >> * they will keep the Fediverse identifiers stable at threads.net >> >> * so if you want follow user pcottle on website threads.com, >> counter-intuitively, you need to follow them as @pcottle@threads.net >> (don’t know whether they will redirect / alias or such, but the >> canonical identifier will remain at threads.net) >> >> * on the pro side: identifiers don’t need to change across the >> ActivityPub network >> >> * also block lists don’t need to change across the network >> >> * on the con side: what do you put on the billboard? Follow cocacola on >> threads.com by following @cocacola@threads.net does not fly very well ... >> >> Note this e-mail isn’t supposed to be about Threads, but about the >> underlying requirement : domain names change, get lost, get taken away >> during trademark disputes, change in governments, because somebody changed >> their mind and what have you. IMHO it would be nice — really important?!? — >> to come up with a better solution in future versions of the spec(s). >> There are various ways this could be addressed, obviously, but regardless >> of approach, an site should be able to end up with their new domain, not a >> weird old/new combo like in this case without the administrators of N-1 >> instances having to do extra work, such as manually editing their block >> lists, or users suddenly facing broken links. >> > > These migration issues always happen. I suggest checking back in 6 months. > > Many of us in the federated space had to do this changing http → https — > it's a pain for a while, but then things settle down. > > There are many competing solutions to this problem, each with trade-offs, > but my favourite is to give user accounts a history over time, which > software can follow. I like this because it strengthens user agency, which > I think is really important for the long term health of decentralized > systems. > > >> >> Cheers, >> >> >> >> >> Johannes. >> >> >> >> Johannes Ernst >> >> Fediforum <https://fediforum.org/> >> Dazzle Labs <https://dazzlelabs.net/> >> >> >> >> >>
Received on Monday, 28 April 2025 19:21:17 UTC