Axel Rauschmayer
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.
Sergey Shandar
@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.
Axel Rauschmayer
@serapath From what I know about Bluesky’s team, I believe that their intentions are good.
But, eventually, they’ll have to make money.
Upside: People have moved once (from Twitter to Bluesky). Moving again is going to be much easier and the Fediverse isn’t going anywhere.
Only potential downside of ActivityPub that isn’t relatively easy to fix: It *may* not scale as well—no one knows at the moment. I’m curious: Could AP handle (e.g.) Taylor Swift joining the Fediverse?
silverpill
>I’m curious: Could AP handle (e.g.) Taylor Swift joining the Fediverse?
Yes.
Today there are ~30000 servers in Fediverse, so to deliver a message to everyone via shared inboxes the server just needs to make 30000 HTTP requests. This is not much, even if account makes dozens of posts per day.
The total number of servers is going to increase, but it will probably plateau somewhere between 100k and 1m.
𝓼𝓮𝓻𝓪𝓹𝓪𝓽𝓱【ツ】☮(📍🇬🇧)
@rauschma bluesky is broken by design. it only purpose is to subvert the fediverse. to sell a narrative and dont delive it so you can later capture and monetize.
bluesky will enshittify and is a lesson to those who are still to naive despite the obvious facts.
some ppl only learn when life teaches lessons, but we can spread the news so some can wake up before they sink more time into those dead ends 🤷♀️
Axel Rauschmayer
@silverpill That makes sense! Per-server caching significantly lessens the load.
One remaining challenge is replies, profile data etc. being incomplete and/or out of date (you are working on that, IIRC). Thanks to per-server caching that shouldn’t cause too much additional traffic.
silverpill
@rauschma Replies can be synchronized between servers, but most people probably don't want to see all replies, I think small servers may choose to pull only most popular ones. We can also make various optimizations, such as activity batching (currently AP servers make a separate HTTP request for each activity delivery).
Sergey Shandar
@rauschma there is also a risk that owner or policies of your fediverse server is changed. No matter how you trust it, anything can happen. Twitter is an example.
Axel Rauschmayer
@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.
Axel Rauschmayer
@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.
Sergey Shandar
@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
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.