- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 28 Apr 2025 21:40:00 +0200
- To: Bumblefudge <bumblefudge@learningproof.xyz>
- Cc: Johannes Ernst <johannes.ernst@dazzlelabs.net>, public-swicg@w3.org
- Message-ID: <CAKaEYhLAwAjx01dYn1rheEiOD7ohdPEpn6Jmk3-Nycy+3-3paw@mail.gmail.com>
po 28. 4. 2025 v 21:21 odesílatel Bumblefudge <bumblefudge@learningproof.xyz> napsal: > 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 > DNS has one point of centralizations, ATP inherits that, and adds a 2nd point of centralization. One of those things that isnt a problem until it is. > > > 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. > What's the IP safety issues? > > 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:40:17 UTC