@dansup We're stronger together, Dan. It's not worth throwing stones.
Uncategorized
243
Posts
50
Posters
0
Views
-
@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 -
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@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.
-
@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.
@dansup@mastodon.social there are walls.. perhaps you don't see them because Pixelfed is large enough that it gets benefit of the doubt.
I got called a VC funded tech bro once, simply because that person found their public posts and profile on NodeBB (because, you know, federation), and absolutely did not back down until their instance's mod told them to quit it.
The smaller devs doing interesting things with fedi get absolutely fucked over for simply exposing the fact that... public stuff is public. 🤯
That's not even getting into any of the tech arguments that make AP federation harder than it should be.
@thisismissem@hachyderm.io @evan@cosocial.ca @quillmatiq@mastodon.social
-
@dansup great example of how money doesn’t equal smarts 🤡
-
@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 -
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 here's the did:plc spec: https://web.plc.directory/spec/v0.1/did-plc
-
@cy @mastodonmigration @baralheia here's the did:plc spec: https://web.plc.directory/spec/v0.1/did-plc
@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
-
@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.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org -
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.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org@cy @mastodonmigration @baralheia because there's a tonne of spam entries in there. This is the public key, handle, services from the DID document, and the rotation public keys. And specifically it's the full changelog for each DID.
There's like 1.5 million spam entries, all referencing trump's domain.
-
@cy @mastodonmigration @baralheia because there's a tonne of spam entries in there. This is the public key, handle, services from the DID document, and the rotation public keys. And specifically it's the full changelog for each DID.
There's like 1.5 million spam entries, all referencing trump's domain.
@cy @mastodonmigration @baralheia did:webvh is also a blockchain then.
Basically you need to have the full did history for a bunch of purposes for like trusting a full DID document from its creation to current state.
-
@cy @mastodonmigration @baralheia did:webvh is also a blockchain then.
Basically you need to have the full did history for a bunch of purposes for like trusting a full DID document from its creation to current state.
I just sign the most current document with a digital signature, and don't bother with links to previous documents. You need the same key you had during creation to add records to your blockchain, so just use that key to sign the records and drop the blockchain. I say, at least.
Otherwise you end up with monstrous amounts of data required just to prove your most recent record is legit.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org -
I just sign the most current document with a digital signature, and don't bother with links to previous documents. You need the same key you had during creation to add records to your blockchain, so just use that key to sign the records and drop the blockchain. I say, at least.
Otherwise you end up with monstrous amounts of data required just to prove your most recent record is legit.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org@cy @mastodonmigration @baralheia nope, you just need a previously signed key, e.g., the rotation key.
But if you want to prove the lineage of a given DID you do need that full history. Hence did:webvh (full history) vs did:web (current snapshot)
did:plc decided that they wanted to retain the full history but typically only surface the current snapshot.
-
@cy @mastodonmigration @baralheia nope, you just need a previously signed key, e.g., the rotation key.
But if you want to prove the lineage of a given DID you do need that full history. Hence did:webvh (full history) vs did:web (current snapshot)
did:plc decided that they wanted to retain the full history but typically only surface the current snapshot.
Rotation key isn't going to prove anything, since the content of the ID is the creation record. It won't match anything else other than the first record.
If (on the other hand) the content of the ID is the public key fingerprint, then it's already proven.
CC: @mastodonmigration@mastodon.online @baralheia@dragonchat.org -
@evan @quillmatiq @dansup the problem is, and always has been, that we keep fighting between the protocols and slinging mud, such that it deters collaboration.
That's why I wrote that damn letter back in September last year. The more this carries on, the more it hurts us all.
In case you need a refresher: https://writings.thisismissem.social/statement-on-discourse-about-activitypub-and-at-protocol/
That actively had people on both sides going "hell yeah, let's work together" and a small group of people decided they didn't like that. Think about how that impacted developer relations. Think about how that harmed collaborations.
Think about the ideas that could have been cross-pollinated and instead we lost them for ActivityPub and for AT Protocol. (though, tbh, I think it's mainly ActivityPub that lost out here, because AT Protocol is so much further ahead in splitting data from applications)
Also, fwiw, Mastodon has had huge investors to keep it alive at times. That €1 Million euros that Eugen was paid didn't come from the community supporting the project on Patreon. That came from one or a few large funders (investors).
@thisismissem donors, not investors.
@evan @quillmatiq @dansup -
@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!
-
@stefan it comes from @laurenshof.
@thisismissem @stefan
id estimate it at 12M MAU, probably a bit higher (this is dependent on the ratio you take for users participate versus lurkers, this estimates that this ratio is the same for DAU as it is for MAU. but likely that this ratio is higher for MAU than for DAU)
https://bsky.app/profile/laurenshof.online/post/3mdisqjlb5s2i -
@thisismissem @stefan
id estimate it at 12M MAU, probably a bit higher (this is dependent on the ratio you take for users participate versus lurkers, this estimates that this ratio is the same for DAU as it is for MAU. but likely that this ratio is higher for MAU than for DAU)
https://bsky.app/profile/laurenshof.online/post/3mdisqjlb5s2i@thisismissem @stefan the reason for doing this multiplier is not so much for getting MAU right in absolute terms, but because mastodon/fedi MAU data also includes lurkers in their data. So you need it to get a fair comparison between fedi and the atmosphere
-
@thisismissem donors, not investors.
@evan @quillmatiq @dansup@renchap @evan @quillmatiq @dansup rich people who believe in the vision and want to see the future you're promising. They might not expect a 10x return, but let's not kid ourselves, they're putting in because there's something in it for them and they get a nice tax write-off.
If your donors stop donating because they no longer believe in the vision/team/etc, then that'll limit the project. You need these wealthy donors to stay happy, as much as Bluesky PBC needs their investors to stay happy.
Wealthy people with money to give/invest in support of a future you've sold them.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@loeven pensa che la cosa più impressionante è che le cose che vengono pubblicate nel Fediverso non invecchiano per niente. Infatti il tuo messaggio è ancora attuale, visto che sono ancora le 7!
-
How would you have done it?
-
@ilarioq solo se prodotte da un multimiliardario sociopatico, però 🤣
-
-
They have to buy the left one.
-
@evan A range of gluten-free sandwiches that don't fall apart as I eat them and don't feel doughy or sandy.
-
@lowqualityfacts He makes them appear in their sock drawers every morning, such is his power!
-
Memory tearing: when you cry after looking at memory prices
