Jack Dorsey skipped ActivityPub, built AtProto, lost Twitter, funded Bluesky, watched it become a company with VCs and a board, said it was "repeating all the mistakes," left, and now funds Nostr.
The fediverse is the only one in this story that never needed a billionaire to survive.
And it never will. 🔥
@dansup I don’t understand why people here feel the need to diminish others’ work to boost their own. ActivityPub is great, but it still lacks things that AT Protocol is actively solving. Dorsey isn’t working on AT Protocol anymore, you already pointed that out. Instead of burning bridges, let’s build them and aim for a more connected ecosystem. If you spend 5 minutes reading what the people over there are saying and their roadmap you would realize they are an ally rather than an enemy!
@dansup great example of how money doesn’t equal smarts 🤡
@dansup It's important to note that Dorsey left BlueSky when Bluesky introduced content moderation. That's what he meant by 'repeating all the mistakes'.
@dansup I'm laughing out loud at how bad the Nostr homepage copy is. What's that law where techbros building communication tools don't understand that communication is important....?
@dansup
Are others fighting to survive or dominate ?
This concept shall henceforth be referred to as .... Chasing Twitter.
@dansup @quillmatiq while I agree on your take on bluesky, the existence of Blacksky and others show that atproto is a viable decentralized protocol and is beyond the control of bluesky, the company. Im hopeful there will be more bridges that will connect that will connect activitypub to atproto like Bridgyfed or services that have interoperability built in like Wafrn
@adamtewodros @dansup @quillmatiq
blacksky should build on activitypub
if they build on atproto, ok
good luck to them
but they seem to be choosing a sinking ship
@benroyce It's our own fault that they didn't, though. Black people have been actively pushed out of this community.
You've probably read this by now, but here it is again.
https://logicmag.io/policy/blackness-in-the-fediverse-a-conversation-with-marcia-x/
And of course: https://privacy.thenexus.today/start-making-the-fediverse-less-toxic/
@stefan @adamtewodros @dansup @quillmatiq
zero argument
i remember reading mekka's posts about the sordid harassment, that us while folks just don't see
that's a struggle we have a duty to help with
i can see jumping to atproto as a valid response
i just fear that whole ecosystem is doomed, because of bluesky
maybe bluesky crashes, and blacksky picks up from the ashes
regardless, it's fruitful to fight the fucking reply guy bigots on mastodon, as an ethos, and with technical improvements
@benroyce Absolutely!
But I'm just not seeing this as being important enough to the development of Mastodon in particular.
When people called out the strong opposition to quote posts as racist, given that the sort of call-and-response style of conversation has been so popular on Black Twitter, I thought this was reaching a bit.
But now we're looking at the most requested feature, the ability to disable replies, which many agree would help with the harassment particularly marginalized voices receive on here, and again, there is so much pushback, as well from the overall community here.
Starting to see a pattern.
@benroyce And yes, we all know there are technical challenges making that happen, but given this was requested back in 2018, it tells you all you need to know about priorities.
@dansup Nostr is a good idea, unfortunately nobody is talking to each other and everyone wants funding from the same wallet.
@dansup We're stronger together, Dan. It's not worth throwing stones.
@quillmatiq hard to see Bluesky as part of a "together", yet Bluesky is still better off without Jack Dorsey, than with.
@sunnythesheep I'm not talking about Bluesky, I'm talking about atproto, which now includes a variety of services, many of which have no connection to Bluesky with their tech stack.
@quillmatiq I see your point. Still love services who stick to ActivityPub, for interoperability, more.
@quillmatiq not throwing stones, just spittin facts. To much glazing over AtProto when many seem to forget its history, so I feel a duty to remind people of this.
ATProto never cared about openness or the social web, or they would have adopted ActivityPub and helped improve it.
They had to control everything. Jack even said he regrets that himself.
@dansup @quillmatiq heya Dan! Going to do the mastodon/activitypub thing - I think you mean Bluesky
ATProto has a thriving community that I and others are part of.
I care about openness and the social web, which is why I spend time with the ATProto community
Feel free to yell at Bluesky-the-company
@dansup @quillmatiq Anuj, this is unfair.
There is a significant difference in intent and governance between ActivityPub and ATProto.
It's perfectly reasonable to point out those differences, just like the atproto.com site points out technical differences.
@evan @dansup @quillmatiq True, ATProto's intent is to cash in and make it's backers rich, ActivityPub's intent is to provide a protocol for an open web.
Thanks for calling that out!
@reflex @dansup @quillmatiq I think Anuj's point is that there is a growing ecosystem around ATProto that is not owned or controlled by Bluesky LLC. There are a lot of people in that ecosystem that are just as concerned about decentralization and distribution of control as we are. Many people in the LLC even support that decentralization. It is a serious bummer that it's splitting the social web, but at least we have bridges and multistack services to connect us.
@evan @reflex @dansup @quillmatiq thanks for summarising Evan. Is there an accessible (non-dev) article available to explain the makeup of the ATProto ecosystem and the chances of it not being a target/surviving without Bluesky? As a tech-aware/non-dev person, I am not interested in the respective merits of the actual protocols, more about each's ability to thrive away from VC (dev community size, culture, capitalist power dynamics... what else?)
Pushing a separate protocol has undoubtedly hurt the entire distributed social networking movement. It was done intentionally.
It shouldn't have worked. ActivityPub should have been more widespread by the time that ATProto launched, so that a competing protocol would have no chance to split the network.
But we weren't, and it did. It's at least partially our fault that a house-brand protocol has been such a serious threat.
@evan @dansup @quillmatiq Evan, perhaps spend some time introspecting why ActivityPub didn't get more adoption and why developers love AT Protocol.
@thisismissem @evan @dansup @quillmatiq What developers love is not a great metric as becomes apparent if you follow the tech industry for a while.
@thisismissem @dansup @quillmatiq This is my number one area of interest!
@thisismissem @evan @dansup @quillmatiq
Why do you think this is Emelia?
@thisismissem @evan @dansup @quillmatiq
Why do you think this is Emelia?
@thisismissem @evan @quillmatiq more adoption, like Metas Threads? There are dozens of projects on the fediverse, more than atproto, so that’s not really coming across as you think it is lol
@dansup So ActivityPub needed VC money, too?
Btw, Fediverse Threads is in maintenance mode and is one-way, basically RSS with likes, so are we going to even consider it a part of the ecosystem at this point?
@dansup Also, I'm sorry, I have to ask - but how many independent services do you think atproto has right now? Because it's not just a handful, as you're making it out to be.
@quillmatiq @dansup @thisismissem @evan
How many Anuj?
And, what constitutes an AT Proto "independent service"?
@mastodonmigration @quillmatiq @dansup @thisismissem @evan I'm curious to know as well. I'm not dead-set against ATproto, and I like some of their ideas on paper, but i only really know of one public full-stack reimplementation that could exist if Bsky disappeared overnight - BlackSky. But last I read (admittedly been a minute), they're still dependent on Bsky for the plc directory, right? I'd like to be better informed if this is no longer the case, or if there are other fully independent full stack implementations!
@baralheia @mastodonmigration @quillmatiq @dansup @evan
PLC directory is in the process of being moved to a swiss association, it's just taking time, because legal stuff always takes time.
https://docs.bsky.app/blog/plc-directory-org
The thing about AT Protocol is that you don't *need* to reimplement the entire stack to be independent. You can push people towards independently hosted PDSes, you can use non-Bluesky relays, you can build your own application and social graph. You can run your own moderation systems.
Bluesky is a tiny subset of what we can do on AT Protocol: microblogging. There's so much more happening: video streaming, blogging, science collaboration, annotating the web, links and bookmarking, E2EE messaging, source control management (git), books and pop culture reviews, Q&A services, a container registry, a package management service, music scrobbling, learning journeys, work profiles, video sharing, etc.
I've probably missed at least a few entire categories here.
ActivityPub forces you to re-implement the entire stack, AT Protocol allows you to do it progressively or reuse community infrastructure.
If you think of AT Protocol as Bluesky, then that'd be the same as thinking of ActivityPub as Mastodon. Far too many ActivityPub developers fall into that trap of "I must be compatible with mastodon" that it stifles innovation.
@thisismissem @mastodonmigration @quillmatiq @dansup @evan I appreciate this information, but my main interest in modern decentralized social media protocols is for social media (microblogging, as well as picture & video sharing), and I am not a developer - just a nerd. My primary concern in all of this is I simply don't trust Bluesky PBLLC. That's why complete and total independence from their infrastructure from a microblogging standpoint is important to me before I would ever consider using an ATproto-based service as my primary social media platform. While I'm okay using community resources for now, I *want* the ability to host my own completely independent full stack so I would never need to rely on a company or community to stand up a relay or AppView or something. I can do that easily and *cheaply* today with Mastodon or WAFRN (the ActivityPub side of it, anyway) or Pixelfed or Loops - it's not a big lift because these platforms were already designed with the full stack as a single deployment. This makes the network highly resistant to adversarial takeover, especially as things exist *right now*. It's a far, far, far bigger lift to stand up a similarly independent full stack of Bluesky (for example), and far far far easier for the majority of the network to be compromised if all statuses must be funneled through corporate or community chokepoints.
Tl;dr if I can't easily host a full stack that can run completely on it's own (while still being able to federate with others), that's not independence. *Every* service built on top of ActivityPub can give me that independence *by design*. It's the difference between human-scale networking and corporate-scale networking.
If there's an easy, lightweight, fully independent way for me to participate in Bluesky-compatible microblogging on ATproto with an experience that is comparable to what I'd get from using Bluesky directly, I'm interested to learn more - because I'm not currently aware of anything like that. I can get that from multiple platforms on AP *today*.
@baralheia Then use Blacksky or similar. They have their own PDS, their own Relay, their own Bluesky AppView, and to a degree own Moderation — they still do query the Bluesky Moderation Service for some stuff though.
So they are effectively entirely independent. They have done experiments with did:web too, though I think they're mostly using did:plc (not 100% sure).
But operating an entire global-scale network is expensive. Bluesky have stated that just generating following feeds is something like the majority of their infrastructure load. There are other projects that seek to not do global-scale, and instead have different tradeoffs.
With ActivityPub, you only have local-scale, which gives you a small perspective of the entire network. There are projects like fediscovery that are designed to facilitate sharing data across otherwise loosely federated boundaries, such that they can do near global scale things.
@baralheia it's also perfectly okay to not want global scale and be happy with local scale. That's a trade-off you get to decide with which platform or protocol you use.
It would seem like this 'global scale' difficulty relates to the aforesaid 'quadratic scaling' issue raised by @cwebber
If, in fact this is true, it is very hard to see how the protocol is actually viable as a broadly decentralized protocol.
Would love to have someone knowledgeable address this.
https://mastodon.online/@mastodonmigration/116064809568107112
@mastodonmigration @baralheia @cwebber no, I mean, processing 2.4 billion posts, 3.4 billion follows, and 13.6 billion likes is a metric shittone of data to process. Serving up feeds to 42 million users (10-15 million monthly active) requires a lot of processing.
Stats from: https://bsky.jazco.dev/stats
It's not even talking about communication at a network layer between PDSes, Relays, and AppViews. That's a different matter, which is where Christine was mostly talking, iirc.
@thisismissem @baralheia @cwebber
Hmmm... please excuse the layman's understanding of these matters, but it does seem like this relates to traffic at the network layer. What you are saying is that the difficulty for the smaller instance in scaling is "serving up feeds for 42 million users." With ActivityPub the first request would transfer a single copy to a cache on the requesting instance and subsequent requests would not generate any traffic. This is why AP is able to scale linearly.
@mastodonmigration @baralheia @cwebber so ingesting all the data for Bluesky does take time & resources, but it is doable: @FedicaHQ have actually done this, as have Blacksky. There's probably others too.
The AppView acts as a cache for this data. The cost is due to the sheer scale of the dataset, and in computing the feeds & notifications for however many million users.
The other cost is CDN and Moderation, which are kinda expensive at scale, however, definitely aren't costs unfamiliar for AP servers too.
Mastodon does an interesting design choice by stopping producing feeds for users that haven't been active for a while.
There's also been plenty of fediverse applications that have had issues with feed generation (Firefish, Hollo, and others have had issues in the past if memory serves).
So yeah, if you only need to serve feeds for say a dozen users and don't need the full network's worth of data, then it's cheaper.
But the article that Christine wrote was more about the network bandwidth between the components and how that scales. Which is a very different matter.
@mastodonmigration @baralheia @cwebber An AppView typically consumes data from a single full-network relay, with failover. A PDS typically has subscriptions from 1 or more relays for data. There are also some relays that just consume other relays.
Adding more PDSes means more connections for relays, adding more relays means more subscriptions to individual PDSes for data.
There's like, a dozen or so relays operating in full-network mode, as far as I know, and relays don't do archival anymore, which was the largest cost.
@thisismissem @baralheia @cwebber
Still not seeing it. On the ingest side, traffic should only be proportional to total users on that node. If a node is smaller it should only generate network data traffic to service its own users. Actually less than that due to caching.
The beauty of AP seems to be precisely that it uses caching to enable individual nodes to scale storage and processing linearly both as regards serving and ingesting data.
@mastodonmigration @baralheia @cwebber right, so on the ingest side, if you want to build an application that is ingesting all the data from bluesky, then you'd be asking the relay for all records targeting the app.bsky.* NSID and all events about repositories that contain the app.bsky.actor.profile record.
That's 42 million accounts across however many PDSes.
That's specifically for an AppView where you *want* a full network copy of all microblogging data. That's obviously going to be expensive.
You can also build a system where you say "Actually, only give me data from these accounts" (partial network copy). Konbini is one such project: https://github.com/whyrusleeping/konbini
Doll's Aurora Prism is another project in this space: https://github.com/dollspace-gay/Aurora-Prism
If I build an app with my own lexicon, I don't need to process all that bluesky data. I process only the data for accounts using my application.
@mastodonmigration @baralheia @cwebber in Christine's article (and I've just spoken with her about it), it assumes a network topology that does not exist in the real world.
It assumes that every user is on a different pds, and every user runs a full network relay. The reality is that multiple users are usually on a single PDS, and there's only like 12 relays.
- 2 from bluesky (+ 1 deprecated)
- 2 from hose.cam
- 1 from blacksky
- 1 from upcloud
- 3 from firehose.network
plus a few more from various people.
In the ActivityPub ecosystem for every user to message every other user, you need connections between 30,000 servers.
For the same in AT Protocol, you need connections between N PDS to one or more relays (most use the bluesky relay, which others get their list of PDSes from).
@mastodonmigration @baralheia @cwebber on activitypub, if I have 30,000 followers (1 follower per server), and I want to post a message, my server has to send out 30,000 messages.
In AT Protocol, if I want to do the same write operation, I send one http request to my PDS, the PDS then publishes that message to N connected relays (where N =< 12)
@thisismissem @baralheia @cwebber
Really appreciate you engaging in this discussion. Will take some time to reflect on what you are saying and try to frame it in generic network model language along the lines of what Christine has put forward.
For this purpose propose we agree that independent nodes be defined as fully autonomous, capable of operating on the network independent of all other components and interacting with all users of on the network (except the PLC directory).
Again, thanks.
@mastodonmigration @baralheia @cwebber well, that's the thing: the network topology does not match that.
Sure, I could run a relay and an appview and a PDS if I really wanted to, but I don't *need* to.
That's where folks are stumbling because they think they *need* to run the entire network topology or stack, which just doesn't make a whole lot of sense for individuals to do.
Instead we pool resources and work together. It's kinda like how there's been the ideas in the ActivityPub ecosystem for ages for a shared media CDN and a shared link resolver for link previews, and even shared moderation infrastructure.
Running everything gets complicated and expensive as the network grows, whether that's AT Protocol or ActivityPub.
@thisismissem @baralheia @cwebber
Well, understand there may be advantages to separating components. However, the entire marketing premise of network 'decentralization' is grounded in the idea of independence of the network nodes. If this is no longer the key design objective, then we really aren't talking about a decentralized network. It sounds fine to say elements share burden and work together, but what happens when a dependent element decides not to cooperate? Isn't this the whole point?
@mastodonmigration @baralheia decentralized *where* and *how*
Is ActivityPub really decentralized when everyone builds for compatibility with Mastodon (apart from Lemmy) or is it only decentralized in operations? Where mastodon.social accounts for a significant portion of the network? What about Pixelfed? How much decentralization there? Loops? I think there's only really one maybe two loops servers of any size?
Decentralization doesn't mean "run absolutely everything myself", I mean, sure, you *could* but that's expensive, complicated, and time consuming. Moderation? Most servers just import some blocklist snapshot at a given point in time.
Thing is, decentralization isn't the goal, the goal is better social apps.
Decentralization focuses on technology, not people. It's the "how" not the "why" and "for who"
Decentralization isn't supposed to make things easier for the people using it. It's not supposed to be a better social "app." That's not the point. The whole reason for decentralization is to prevent admin abuse. You put up with a little more hassle as a user, and when the admin sells you out to Nazis, you'll be ready to adapt. Then sellouts don't take over the network, and nobody gets their elections rigged in favor of some tyrannical monster, or whatever.
Criticizing Activitypub for having an optional server that has too many people on it is fine, but you can't equate that to a network run by crummy venture capitalists who worked for Twitter, that won't function without permission from one central authority.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org
@cy @mastodonmigration @baralheia you have no idea how close to a sell out that almost happened we came, and how it would've affected a significant portion of the fediverse.
They hid that from you.
AT Protocol does and will function without a central authority. Sure, we all use did:plc for identity pretty much, because it's a good trade-off for most people. But did:web is also supported, and the working group at IETF specifically is chartered to allow new DID methods to become part of the network.
Can you use ActivityPub without Webfinger support? That's something Mastodon forced on the network, and everyone else had to adopt if they wanted to federate with Mastodon.
(Hint: you can't choose *not* to do Webfinger with ActivityPub, because you won't be able to interoperate with most of the network which requires webfinger).
Edit: Also, Dan posts almost too frequently about *not* selling out, which is mildly disconcerting.
Yeah, but webfinger is just responding to certain URIs on the same server that your instance is, and it really isn't necessary for anything other than resolving the email-y Twitterlike mentions to APIDs. It's not like there's some central webfinger server that every one must finger.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org
@cy @mastodonmigration @baralheia true there's not a central webfinger server one must finger. But that comes with a trade-off that your identity is permanently tied to your server.
That's why account migration is lossy and why you need to create a new account just to change your handle.
If you don't do webfinger as an ActivityPub software implementer today, you'll have a hard time interoperating with the rest of the network who expect webfinger, because back in the distant past Mastodon decided webfinger was the technology to use. In fairness, DIDs didn't exist yet, only some of their nascent ideas did (that's where alsoKnownAs comes from in AP)
There's a thread somewhere here that was like "ActivityPub was never designed to have usernames or handles or anything like that, just actor ID URIs"
Microblogging doesn't really work if you can't @mention someone, as far as most people are concerned.
Also, you don't *need* DID PLC to do AT Protocol, you can totally use did:web, it just has a trade off like that of using webfinger: your identity becomes tied to a domain name.
Here's how you do did:web: https://whtwnd.com/bnewbold.net/3mdc7fpbxhk26
It's pretty manual because it's a pretty technical way to do things. Some PDS implementations may do did:web by default, but that article is covering the reference pds implementation, that doesn't focus on did:web
But that comes with a trade-off that your identity is permanently tied to your server.Au contraire! Even without webfinger, the Activitypub APID starts out with https://yourinstance.com and you aren't allowed to publish digital signatures, so account migration is lossy no matter what you do! If your instance bans you, or goes down forever, then your followers are gone gone gone!
That's why account migration is lossy and why you need to create a new account just to change your handle.
@myfriend it would autocomplete that to @myfriend@12345678901234567890... without querying your friend's last known instance.@cy @mastodonmigration @baralheia yeah, so, um.. FEP c390 isn't supported by 99% of the fediverse.
I'm not saying all DID methods are great, hell no, I'm saying that they have different trade-offs. did:plc has a different trade-off to did:web, if you like webfinger, you'll probably like did:web, because you understand and accept that trade off (hopefully).
A did:plc is actually using your private key to sign the initial create operation for your DID document, and then that becomes your did:plc:<whatever>
AT Protocol mandates that both did:plc and did:web must currently be supported for wide interoperability.
You should probably just ask someone like Dmitri Z. or Bumblefudge about the history of DID's and ActivityPub Actors.
For that client you describe, try friendica or similar software. Or, you know, feel free to build your own software, no one's stopping you, but.. oh whatever, go have all the fun. I won't spoil it for you.
did:key is great but it's not resolvable, without specifying a service to which it can be resolved by.
Sorry, I try to understand all this stuff but it's hard to wrap my head around it so I probably get a bunch of stuff wrong.
Dunno about plc, but I do like "did:key" whose corporate sponsor is ehm... "Rick Astley (thank you for your inspiration)." The identifier is a public key fingerprint, the FEPs can help with sharing the key for that fingerprint, and you're good to go. Any client seeing someone claiming to be the same person can merge the accounts if they have the same public key.
As for "it's not resolvable" um... yeah, you have to give people a DNS resolvable APID to start, but once they have your key then you're no longer bound to it. Are you saying PLC has some sort of totally-not-DNS server, to resolve keys to their corresponding instance? Like a PGP keyserver? That'd be nice, I guess. Just not sure I understand correctly.
As for friendica, no, fuck no, do not point people at friendica. They thought up their nomadic accounts with no understanding of cryptography in the slightest. They propose sharing your private key with multiple instances, that's how bad it is.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org
@cy @mastodonmigration @baralheia so like, if I wanted to, I could have a local copy of the entire did:plc registry, it's like 130-145 GB uncompressed, including indexes.
Then I could resolve a did:plc by asking my local database. At some point I've heard there'll be a websocket API for it too. There's a project "allegedly" that helps with mirroring, like what https://plc.wtf does
But most people don't care to replicate that, and instead use the HTTP API
Why on earth is it 130-145 gigabytes?? A public key can be like... 64 bytes these days, so that would be at least 2 billion keys.
What I'd do is have each instance let you search for keys it knows, and if someone updates their key it doesn't keep the old key. But I dunno, I can only guess that would be much smaller than... that.
Updates after initial creation contain a pointer to the most-recent previous operation (by hash).O lawd it's a blockchain.
@evan @dansup What's hurt it more is not working together on a unified strategy and putting up walls every time there's a chance to do so.
There are folks on the atproto side who have shown an intent to bridge with services like Pixelfed and Loops, *including* adding the logo on the posts to help promote services. We can either move together, or we can continue to push each other away and fall to trillion-dollar companies building their own ecosystems, some of whom the Fedi bet the farm on.
@quillmatiq I like your vision of peace and collaboration. But when there is a working protocol and a team builds a completely new one that is not compatible with the existing. Who is building a wall? When I want to build a new "open social web" service or client, how many protocols should I need to implement? This is not about if mastodon or pixelfed could be Atproto compatible, it's not about services it's about the protocol. @evan @dansup
@quillmatiq @evan @dansup I have been thinking about trying to do some sort of protocol bridging with my project Fedi+ but then that runs the risk of people like FediTips getting on the wrong side of things being like oh Fedi+ interacts with fashists or whatever all because of the protocol being associated with Bluesky, which verified ICE and other US government accounts, and so on. My goal with Fedi+ is to not only create that vibe people loved when Google+ was around, but also to make it super easy for people who don't care about Mastodon or ActivityPub or whatever to join on and not even need to think about the protocols behind the scenes.
@quillmatiq @evan what walls? The fediverse literally worked with Meta for Threads federation, we’ve been here and open to collaboration, they went off and made a worse implementation that is even more difficult to full self host.
I appreciate the ability for interop, but I’m not wrong about this.
I think there is a lot to applaud in the ATProto community in terms of the growing openness, the standardization of part of the stack, and the great work engaging third-party developers.
If ATProto can overcome its origins and single point of failure, great.
But it's gross to gaslight ActivityPub developers that those origins don't exist and it never happened, and don't talk about them when strangers are watching.
@dansup This is such a miscommunication of what's happening. Happy to chat with you about it sometime, but I highly recommend not taking a billionaire's word over what that ecosystem is and what it's meant to be.
@quillmatiq
Aren't the billionaires the ones designing the ecosystem now?
