Recent searches
Search options
Administered by:
Bluesky says that: “Never lose access to your followers or data.”
However, I don’t think that’s true. Can someone confirm?
Even in a scenario where there are multiple Relay/AppView/Labeler services, if you move to a different service:
• You can only follow a user if their PDS is crawled by your service.
• A user can only follow you if your PDS is crawled by their service.
@rauschma I think, we need to have an online open meeting or something like that. Because there are a lot of principles that are different with proper decentralization that are difficult to answer using centralized terminology. E.g. protocol has a different meaning in decentralized systems, it's more a math proof than transport logistic layer. BlueSky supports DID but I need to learn more. We need to change the way we think about digital space.
@functionalscript
For me it’s mostly about avoiding lock-in. And the Fediverse does that well enough (for my taste). Hopefully, it’ll eventually support domains or URLs as user handles. Which shouldn’t be too difficult(?)
But there is definitely room for something even more decentralized—especially for people who have a high risk of being censored such as dissidents of totalitarian regimes. Such a solution will have different pros and different cons.
@rauschma there is also a risk that owner or policies of your fediverse server are changed. No matter how you trust it, anything can happen. Twitter is an example.
@functionalscript But if your user handle is a domain name (where a TXT record mentions the current server) then moving to another server is completely transparent.
One could also do a simple form of content-addressing:
my-server.example/@user.example/12345
Such a URL could be routed to the correct server via the user handle. Then the path would work on every server. For complete transparency, one could use a domain that points to the current server.
That would be good enough for my needs.
@rauschma Agree, people have different requirements. But we need to understand risks. There is still a risk that you forgot to maintain your domain, for example expired credit card. A proper DID is virtually forever with zero maintenance. https://github.com/did-method-plc/did-method-plc?tab=readme-ov-file#how-it-works
