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.
-
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 It's important to note that Dorsey left BlueSky when Bluesky introduced content moderation. That's what he meant by 'repeating all the mistakes'.
-
@alexchapman @quillmatiq @evan @dansup @HolosSocial
and it has implications on innovation.
We/I could build a LinkedIn (when LinkedIn was good) version for the fediverse.
A nice professional UI fediverse-client that shows indexed #jobs posts, adding @badgefed / certifications celebrations, and some #lemmy forums on specific companies and job market. But I am afraid that simply indexing (even if done in the "right and respectful" way), would get a drawback.
Couldn't it be done with a mastodon server specifically for jobs on the back end with a front end reworked to LinkedIn?
-
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.
-
@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 -
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
-
Honestly, it has nothing to do with fighting each other. The concern is the continued dependence of AT Proto on Bluesky PBC, and what happens if the management of the company asserts an agenda. But, that is a discussion for another forum.
@mastodonmigration @thisismissem @baralheia This is the main question.
-
@baralheia @mastodonmigration that's the thing: we're comparing apples to oranges.
Yes, it is expensive and complicated to run an entire appview for 42 million users and process billions of records/events. Just like it's expensive to run hachyderm or mastodon.social (granted they're perhaps cheaper because they're a hundredth the size)
You're comparing your mastodon server which does a slice of a pie, with a bluesky appview that does the entire fucking pie, where your slice is less than 10% of the network.
Of course that is different. Anyone can see that's different, I would hope.
Like I've repeatedly said: you can run the whole pie if you want to, but you don't need to, and in fact, some people have decided that they want to, like Blacksky, and Eurosky (but they're not there yet)
The number of relays can always grow. The number of PDSes can always grow. Same with the number of independent app views. I have my own appview, but it doesn't do microblogging or bluesky stuff, because that's not what my app is about.
When 43k+ servers are 71.1% Mastodon and 11% Pixelfed (by active accounts), or ~30% each Wordpress and Ghost and 20% Mastodon by number of servers, are you really in full control? Sure, you can operate the software, but is that really "control"?
The "control" we say we have only makes us "feel good", if mastodon.social decided to defederate from you, would your Mastodon experience be the same? (you wouldn't have been able to see a significant part of this conversation, since they run mastodon.online too)
AT Protocol can scale down too: https://bsky.bad-example.com/can-atproto-scale-down/
The components of AT Protocol are cheap to run, PDSes and Relays both run on commodity hardware. It's the full-network aware AppView that is a specialized piece of software, but even without that you can still interact with the network, see Red Dwarf: https://reddwarf.app/
I guarantee you there are way more people hacking with AT Protocol than ActivityPub-based systems. The Mastodon codebase is a beast to understand fully, and I say that as someone who has been a regular contributor (100+ pull requests merged)
@thisismissem @mastodonmigration I do think we're talking past each other, and probably because we're coming at this from different perspectives. I'm a user and a nerd, not a developer or an admin. I'm not intending to argue and I apologize if I'm coming across that way - I value your contributions in this thread quite a lot, thank you! You're clearly much more experienced with ATproto and Bluesky than I am, and I've learned quite a bit tonight from your posts!
When I compare the two, I'm trying to communicate what I am looking for from my social media experience, and what I think is important from my perspective in avoiding the same sort of enshittification that the legacy centralized social media networks have suffered from. Part of this comes from an (apparent) misunderstanding that not all components of the Bluesky tech stack are actually required to participate. I'm playing with Red Dwarf right now (again, thank you!) and this looks promising - I want to see more projects like this, projects that bypass the heavyweight, individual-unfriendly components of Bluesky to still offer a view of my friends list and friends-of-friends too. I'm going to play more with Red Dwarf!
On the topic of control - yes, if the SHTF and I could operate my own stack of the components required to participate in the network, that meets the level of control (and decentralization!) that I'm seeking. If for some reason I felt I could not trust any other instance, I could still easily stand up the minimum number of components required to fetch and view statuses from the users in my friends list (including boosts and quote-boosts), and serve up my own statuses in a way that those who follow me can still see me - that's the level of control over my user experience I want, with no middle-man/relay necessary. The majority of my friends are furries that are on furry-fandom-specific instances, and while nice to have, I don't really care about always having a full global view of the entire network - I care about what my friends are up to.
-
@mastodonmigration @thisismissem @baralheia This is the main question.
@skarnio @mastodonmigration @baralheia as someone *actively* developing on AT Protocol, I can tell you that Bluesky PBC could disappear tomorrow, and we'd just work around it. There's complete mirrors of the did:plc directory, and we'd just pick one to replace the existing directory. Sure, it'd be hugely disruptive, but life would go on. We would work around it.
There's alternative relays, hostile migration of PDSes is possible, and changing the plc directory is possible. Blacksky probably couldn't handle all of Bluesky's users suddenly all using it, because they're still new, but *shrug* life would go on.
-
@thisismissem @mastodonmigration I do think we're talking past each other, and probably because we're coming at this from different perspectives. I'm a user and a nerd, not a developer or an admin. I'm not intending to argue and I apologize if I'm coming across that way - I value your contributions in this thread quite a lot, thank you! You're clearly much more experienced with ATproto and Bluesky than I am, and I've learned quite a bit tonight from your posts!
When I compare the two, I'm trying to communicate what I am looking for from my social media experience, and what I think is important from my perspective in avoiding the same sort of enshittification that the legacy centralized social media networks have suffered from. Part of this comes from an (apparent) misunderstanding that not all components of the Bluesky tech stack are actually required to participate. I'm playing with Red Dwarf right now (again, thank you!) and this looks promising - I want to see more projects like this, projects that bypass the heavyweight, individual-unfriendly components of Bluesky to still offer a view of my friends list and friends-of-friends too. I'm going to play more with Red Dwarf!
On the topic of control - yes, if the SHTF and I could operate my own stack of the components required to participate in the network, that meets the level of control (and decentralization!) that I'm seeking. If for some reason I felt I could not trust any other instance, I could still easily stand up the minimum number of components required to fetch and view statuses from the users in my friends list (including boosts and quote-boosts), and serve up my own statuses in a way that those who follow me can still see me - that's the level of control over my user experience I want, with no middle-man/relay necessary. The majority of my friends are furries that are on furry-fandom-specific instances, and while nice to have, I don't really care about always having a full global view of the entire network - I care about what my friends are up to.
@baralheia @mastodonmigration I'm super experienced with AT Protocol, ActivityPub, AND Solid.
What you as a nerd are looking for from social media software is likely very different to the majority of folks out there. AT Protocol is designed to allow a path away from Bluesky PBC, but it doesn't force you to take that path *yet*.
Just because a big beefy AppView like Bluesky is the main way folks interact with the network for microblogging, it doesn't mean it's the only way.
You could totally spin up all the tech reddwarf uses and still interact with the network. In fact, I was just chatting the other day with the guy behind Microcosm about spinning up some of those services myself, and he was like "oh, yeah, totally doable". Spinning up a relay and microcosm is totally doable.
So like, the point about you just wanting to connect with your friends, that's totally valid, and like, for that you don't necessarily need a global view of the entire network. But for other things you do possibly want that (discovery, search, trends, etc).
Everyone has different ways they use social media, for some folks, the Fediverse with it's individual servers and how it works, will work better for them. For other folks, AT Protocol and full global views of the entire network will work better for how they interact with social media/networking.
That's why the very start of this thread started with a "We're stronger together" comment. Neither ActivityPub nor AT Protocol alone is going to be the best for all people, because people have different requirements and desires.
If Dan didn't throw stones at AT Protocol, and say, jumped on a call with the folks behind Skylight.social and Sprk.so (both of whom have a tiktok like experience), maybe they'd find common ground and like bridge the content and that'd be a benefit to *both* platforms.
Dividing people is easy. Uniting them and fostering collaboration is hard.
-
@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.
Seriously though, I think you're talking about the "did" schema in general. "did:web" certainly is no better than "https://yourinstance.derp" and the many DID methods each with a shitty corporate sponsor are mostly just shitcoin blockchain bullshit. However, certain methods such as "gns" and "ipid" do use public keys in a uh... very complicated way. Those could (in theory (technically)) let you migrate accounts seamlessly, or even have multiple accounts on multiple instances all associated with the same identity.
There's also the Identity Proofs FEP which would make account migration super seamless, but you couldn't have multiple simultaneous instances.
And in all cases, webfinger can just return that URI when queried for at who at what instance. Any mentions would resolve to the public-key-based ID in the JSON, as long as the instance was playing nice at the time of that post's creation. So webfinger is not a huge deal. Messy, but how else are you going to turn a mention into a URI?
Personally I'd like a client that didn't have mentions in the post content at all. Instead, you have a second interface where you can add people, like with email "To" and "Cc." Then I'd make it so my client remembered public key based APIDs, so if you typed@myfriendit would autocomplete that to@myfriend@12345678901234567890...without querying your friend's last known instance.
It's just ... the only public key based APIDs are those "DID" things, which are super overcomplicated and skeezy. Isn't there a "PGP" method for DID, or something?
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org -
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.
Seriously though, I think you're talking about the "did" schema in general. "did:web" certainly is no better than "https://yourinstance.derp" and the many DID methods each with a shitty corporate sponsor are mostly just shitcoin blockchain bullshit. However, certain methods such as "gns" and "ipid" do use public keys in a uh... very complicated way. Those could (in theory (technically)) let you migrate accounts seamlessly, or even have multiple accounts on multiple instances all associated with the same identity.
There's also the Identity Proofs FEP which would make account migration super seamless, but you couldn't have multiple simultaneous instances.
And in all cases, webfinger can just return that URI when queried for at who at what instance. Any mentions would resolve to the public-key-based ID in the JSON, as long as the instance was playing nice at the time of that post's creation. So webfinger is not a huge deal. Messy, but how else are you going to turn a mention into a URI?
Personally I'd like a client that didn't have mentions in the post content at all. Instead, you have a second interface where you can add people, like with email "To" and "Cc." Then I'd make it so my client remembered public key based APIDs, so if you typed@myfriendit would autocomplete that to@myfriend@12345678901234567890...without querying your friend's last known instance.
It's just ... the only public key based APIDs are those "DID" things, which are super overcomplicated and skeezy. Isn't there a "PGP" method for DID, or something?
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.orgOh right the "key" DID method uses public keys, pretty straightforwardly. That's what the FEP refers to.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org -
C crossgolf_rebel@moppels.bar shared this topic
E energisch_@troet.cafe shared this topic
