@dansup We're stronger together, Dan. It's not worth throwing stones.
Uncategorized
243
Posts
50
Posters
0
Views
-
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.
-
@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.
@renchap @evan @quillmatiq @dansup your roadmap is also largely determined by whatever you can get money for. The argument of investors in a PBC vs donors in a non-profit is silly because you're both taking money from extremely wealthy people to survive long enough to hopefully be sustainable without those big cash injections.
You've almost certainly had to make promises to donors to get them onboard.
It might not be a promise of a return, but wealthy people are still exerting some control on the project.
-
@renchap @evan @quillmatiq @dansup your roadmap is also largely determined by whatever you can get money for. The argument of investors in a PBC vs donors in a non-profit is silly because you're both taking money from extremely wealthy people to survive long enough to hopefully be sustainable without those big cash injections.
You've almost certainly had to make promises to donors to get them onboard.
It might not be a promise of a return, but wealthy people are still exerting some control on the project.
@thisismissem You are wrong here, those donations were not made in exchange of any specific features.
This is the case for grants where the money is in exchange of specific deliverables, but those donations were not grants.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@Fbrzvnrnd che semi?
-
@eniko big mood
-
In fact, Hackers' Pub is a bleeding-edge testbed for Fedify. 🙄
-
@DigiDavidex ma hai provato a spegnerlo e riaccenderlo?
-
@kaveman Thanks, I didn't know about that work.
-
Current status:
-
@repubblica @calcio-e-sport-repubblica abodi meloni dimissioni
-
@gmarcosanti eh, devo imparare a tenermi l'inverter in macchina così non raccatto tutto da questo mondo 🤣 avevo visto il pannello buono controluce e così ho pensato che fossero morti i soliti condensatori sulla scheda di alimentazione, e invece quella funziona benissimo. Meglio così, posso provare a rivendermi la scheda 🤣
