Comment by rafram

19 hours ago

How will this end up going any better than Mastodon has?

Near inevitabilities:

- All the small instances defederating from the largest due to politics/spam/annoying noobs/whatever, effectively killing the easiest path to entry into the community

- Pointless debates about whether it’s OK to federate with instances that host pirated content, disagreeable politics, furry VNs, etc., which everyone has to take a side (the correct side) on

- Relatively little actual work/productive discussion going on, since many users are there mostly for the politics / fediverse posturing than for actual work

Atproto isn’t “many servers sending messages to each other”. It’s structured more like RSS:

1) there’s an app-agnostic hosting layer (and anyone can run a host, a bit like personal site with RSS)

2) then there’s apps, which aggregate over data from all hosts (a bit like Google Reader or Feedly)

So there’s no such thing as “defederating”. You don’t have many copies of Tangled beefing with each other. It’s more like you can run your own hosting for your own data (if you want), and anyone can build an app that aggregates from everyone’s data (Tangled is one such app).

If this got you curious, I have two longreads: https://overreacted.io/open-social/ (conceptual) and https://overreacted.io/a-social-filesystem/ (diving into the data model).

  • > Atproto isn’t “many servers sending messages to each other”. It’s structured more like RSS

    Except that, crucially, RSS/Atom plays well with static nodes (e.g. personal websites generated with Jekyll/Hugo/whatever—or even written by hand[1]), and Atproto does not. (Nor does Mastodon; previously: <https://m15o.ichi.city/site/writing-atom-feed-manually.html>

    • Atom is pull, Atproto is push.

      Atom was designed for news, before social media existed, where 15+ minute polling times were (borderline) acceptable. Atproto was designed for social media, in an age of Twitter users getting their news in seconds, to the point of being able to comment on live events play-by-play. There's no coming back from that world.

      With that said, I wish both Mastodon and Atproto supported opt-in pull-based, static sources.

      3 replies →

    • There's always some Gemini protocol faction that shows up to yell that everything is wrong and we have to keep hand assembling our packets by hand or it'll never work.

      Atproto's PDS is the root idea that everything extends off of, is the "social filesystem" that you control. There's a protocol objective to be able to spread your data around widely and for folks to be able to cryptographically check that that data came from you (even if you have to change hosts or even if someone sneakernets your data around). That's going to have some complexity! But it allows aggregation, is essential to how we are able to syndicate data so widely in atproto. It's so important it's in the name: Authenticated Transfer protocol.

      And that in turn enables systems like Tangled here to be built, that layer stop the personal data servers, and relays. These work because there is identity.

      If you need your static site to be on atproto (yay!), you can just have one of the various PDS hosts (such as Bluesky or eurosky or black sky or npmx) host the PDS for your. Since it is authenticated and user sovereign, you can permissionlessly move to a different host whenever you please, should that go awry. It's unclear to me why static site needs are an interesting or useful target that social networking ought conform to.

      If you want to make a simpler network where we don't have those guarantees, please go right ahead. It feels to me like a snap reaction though that doesn't bother weighing what we have gotten or why things are this way, that is reflexively demanding.

      6 replies →

  • The web is already structured like this. You can poll a URL for updates. You can host your own data. Anyone can build an app that aggregates from everyone's data.

    • Yes, all of those things are possible. Now imagine a protocol built from the ground up for those purposes, not just possible, but the entire community and ecosystem embracing those things.

      2 replies →

    • > Anyone can build an app that aggregates from everyone's data.

      Unless they gut or disable their API, and then ban scrapers, although I understand why after seeing bots crush sites.

      1 reply →

ATproto federates in a very different way than Mastodon. There is no concept of "instances" on ATproto.

Your account is hosted on a PDS and you sign into the app with your PDS sign-in and records go to your PDS, but everything on the app is from what's called an "AppView" which provides a centralized view of all data in all PDSes so it feels just like you're using a regular centralized app. But there can be multiple AppViews and AppViews can be self-hosted.

So unlike with Mastodon, it doesn't matter what PDS "instance" you're on because the app layer is completely separate from it.

  • > There is no concept of "instances" on ATproto.

    Regardless of name and precise technical details, there are central service components that can ban you. If a proper ecosystem of those ever springs up then the equivalent of fediblock (ie guilt by association) oriented at individual accounts or PDS is the next logical step. At present (last I checked) there's only (approximately) one primary provider plus blacksky making the situation even worse.

    This isn't some wild hypothetical - we also see guilt by association in the matrix ecosystem.

    • Details matter. Technical details matter.

      Most bans today are at the "appview" level: the big indexed view of all the data, that combines the firehoses ("relays") marks accounts as banned & doesn't show their stuff. But the relay and the PDS still work.

      Agreed that there aren't many public appviews for Bluesky posting right now, really just the two. Tangled itself though is an appview, of a different sort: one not for posting but for git issues/pr's/rtc. This appview isnt gated on Bluesky or Blacksky's permission. And folks could pretty comfortably host Tangled aplview themselves, subscribing their Tangled instance to any of the dozens of firehose/relay instances, getting all pre-filtered Tangled activity. And that really is quite decentralized a model that is imminently doable. Regarding the technical properly, the concern here about banning feels premature & naive: it assumes Tangled depends on these appviews at all, and it doesn't.

      I will note that Phil's constellation project just tackles the key reverse indexing that comprises much of the appview work: taking all the firehose records, and connecting all the threads and likes together. Constellation runs ok as a public service on an rpi. There's a lot of challenges to making new appviews, but it is astounding and comforting seeing the core indexing for a sizable multi-media social network running on an rpi. What seems like a dire situation may actually be opportunity, if folks actually tried.

      Whatever problems we want to foresee dooming us, whatever slopes we want to hypothesize sliding down, what we have here sounds way way better than anything else available to me today. Personally I'm much more bright blue sky sunnier about the prospects rather than your dark raincloud doom fall scare-away. The risk imo is immensely more weighted in not trying more than trying.

      1 reply →

    • Don’t they already have extensive block lists that you can “subscribe” to? I think some official blue sky account was added to some and they got super mad?

      2 replies →

To be fair, Mastodon is actually surviving.

Comparing open source social to algorithmically based social is never going to work, that's like saying the Light Phone isn't as popular as the iPhone, so its a failure.

The question is, does it work for you ? If over time open social gets a toehold then it will be an option people know about and can choose.

Not in expert in either but ATProto services (what they call AppViews) are substantially different from the fediverse because they rely on a shared relay instead of explicit federation.

I'm conflicted about the costs of what is currently effectively global discovery, but it's not just another Mastodon.

E: I think its funny multiple other people said the same thing in the time it took me to write this

  • Note a relay is a perf optimization and doesn’t have to be a single shared chokepoint.

    These days running a relay is fairly cheap (~$30/mo?), there’s maybe a dozen of them, and some apps don’t use one at all (instead relying on services like https://constellation.microcosm.blue/ for querying backlinks).

As well as a confusing onboarding where users have to pick an instance, something both incredibly important, but with very little info to base your decision on. Pick the wrong one and your project gets screwed when the random anonymous instance owner decides to shut it down or go on a power trip.

Resulting in everyone just picking the "default" instance.

  • >Pick the wrong one and your project gets screwed when the random anonymous instance owner decides to shut it down or go on a power trip.

    You say this as if it happens often, but it's more likely that a smaller instance will go under because of costs, and there are tons of perfectly fine instances where this doesn't happen at all.

    Also you can join more than one instance.

    Also it costs very little to host your own instance.

    This is not a problem that exists for most people using Mastodon.

    I agree the onboarding process is a bit confusing but really it isn't much more confusing than subscribing to a subreddit, except your identity only exists on that subreddit rather than a separate account.

    Which I would definitely agree is a flaw but not an insurmountable obstacle.

How is any of this a bad thing? Isn’t the whole point to be able to do whatever you want in your corner of the federation?

Also, tangled is atproto based, the big blue mothership will always be in control.

You overexaggerate, but even so, that would be a huge step up (even if imperfect) from bring dependant on GitHub and GitLab for you to be relevant.

> - Pointless debates about whether it’s OK to federate with instances that host pirated content, disagreeable politics, furry VNs, etc., which everyone has to take a side (the correct side) on

Why do you have to take a side / take the correct side? Can't you either just not take any side or take whatever side you feel like and go with that?

  • On Mastodon, if you take the wrong side, those on the correct side will defederate from you. Not merely because you host (or don't host) the content they like (or dislike), but because you merely enable (or discriminate against) those who host that content.

    Of course, all sides are wrong in somebody's eyes; so no matter what you do, you will be defederated from by at least somebody.

    The way Mastodon works, defederation irreversibly breaks all follow relationships, without notifying those involved. If you disagree with the decision, you can migrate to another server, but you won't get your followers / followees back, not without everybody involved doing a lot of manual drudge work. This is just one way in which the myth of "users are free to do what they wish, if they disagree with the admins, they can migrate somewhere else" breaks.

    To make matters worse, there's no way to see which users that you may wish to follow are / will be hidden from you if you choose a given instance. Defederation lists are a (somewhat open) secret; it's good practice to announce defederations, but there's no automated API endpoint to see them, so there's no way to answer the question of "who am I going to lose if I migrate from x to y."

    • > On Mastodon, if you take the wrong side, those on the correct side will defederate from you. Not merely because you host (or don't host) the content they like (or dislike), but because you merely enable (or discriminate against) those who host that content.

      Ok, so? People block you all the time because they don't agree with you, why is that a problem? If people don't want to hear what you say, shouldn't they be allowed to not listen?

      Personally, I don't understand that point of view of blocking people who you disagree with, for me the point of the internet is to find different views and perspectives, but I'm also fine with others filtering out whatever I say, doesn't really impact me either way.

      If you want no rules what you say, run your own instance. Depending on what you say, some people will want to listen, others will want to filter your opinion away, I don't think either sides are "wrong" for that, it's just like in real life. If you want to use someone else's instance, you follow their rules. It mostly isn't harder than this.

      9 replies →

    • > there's no way to answer the question of "who am I going to lose if I migrate from x to y."

      Ahckchually, once you create an account you can use the API endpoint for remote lookup to test in an automated manner which nodes are and aren't reachable.

  • They'll then defederate also from you. The argument goes, you're a nazi/facist/racist/*phobe, because you associate with (== did not defederate from) the designated nazi/facist/racist/*phobe.

    Yes, it's that toxic. Go subscribe #FediBlock hashtag if you don't believe me.

    • Ok, so what? Let those people block you then, sounds like people you probably don't want to interact with anyways?

      I've seen that, and I'm not sure what's supposed to be toxic. It's community-organized filtering of unwanted views, for the people who want to engage in that. I don't agree with that, so I don't participate or do that myself, and I also don't seem to face any negative consequences because I'm not participating in that. What am I supposed to be sad about here, that some people don't want to listen to my views?

      3 replies →