@dansup We're stronger together, Dan. It's not worth throwing stones.
Uncategorized
243
Posts
50
Posters
0
Views
-
@thisismissem @mastodonmigration @cwebber Personally, I don't agree. I'm not at all saying that pooling resources is bad - far from it, actually, because every instance on the Fediverse both large and small is a shared resource (excluding those that are single-user instances, naturally) - but I also think it's vitally important that the network is built with the expectation that individuals CAN and SHOULD be able to own their own *full* slice of the pie, do so easily and cheaply, and be able to expect to have a reasonably similar user experience (even if it's not a global view). US and global politics being what they are right now, combined with seeing how Twitter enshittified the way it did, it is *massively* important to me that my social network is difficult to manipulate or control. 12 relays are much easier to exert some level of control over vs 43k+ active servers in the Fediverse (https://fedidb.com). Same goes for the independent appviews, however many of those are out there. I may technically have choice, but the limited number of relays and AppViews that are fully independent from Bsky is still a liability - and the current architecture makes it more difficult for an individual to manage.
Meanwhile, if I need to have full control over my stack in the Fediverse, all I gotta do is set up a server and throw Mastodon on it. Boom, done. I'm running fully independently now. The only external dependencies would be on the instances hosting the accounts I wish to follow. Hell I could even run this on some really limited hardware and still have a reasonably cromulent user experience.
The idea is not necessarily that such a setup should be the default - but that it should be easily possible when desired or necessary. Make the components of the network so easy and cheap to stand up yourself that it becomes supremely resilient in the face of hostile actors - anyone can stand one up with a minimum of resources. That ease of hosting also makes it easy and fun to play with and hack on and innovate from.
@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)
-
@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 -
@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 -
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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Pubblicato nel gruppo @attualita
-
This post did not contain any content.
-
From: @USAToday
https://flipboard.com/@usatoday/sports-caec6s8fz/-/a-WhXe2Zc-S7K5JTsE-hi16A%3Aa%3A3199709-%2F0
-
È incredibile, la Merkel
Così importante, oggi così irrilevante
-
@alice those reps really ruined it for my generation of doctors
-
@Szescstopni The problem with forests is that they burn.
-
@mcc Oh! Yeah. It's because they don't have a well-defined canonical composition order, unlike modern Jamo, which do.
A weird bit of trivia: there is no composition for hanzi/kanji/hanja/chữ Hán characters (what many call "Chinese characters"). You can't just build one in Unicode. If you could, they'd also be in this list, for the same reason that Old Hangul Jamo are disallowed (which were only added because scholars needed them).
