81–90 of 109 posts
Seems very similar in goal to the Solid Project, https://solidproject.org , which Tim Berners Lee is involved with and is being standardized by the W3C.
I'll definitely bookmark this.
But also appropriated to control modern GSM and LTE chipsets, SCADA radio modems and who knows what else.
I hope my search results won't get polluted with this too badly.
If a team can't work within an existing standards body or a community (like the ActivityPub contributors) then they simply can't create an actually decentralized and open protocol/network. They can, however, create something that they can define and control for their own gain. Rolling out this protocol on a site without a community forum or other discussion channel but simply a "give us your email address and we'll l…
My main concern with the protocol design is in the identity, and how it lends itself to centralized name services (@alice.google.com). The end result seems like it will be no different than Mastodon and email protocol, where a few central players own the majority of the namespace and network effects prevent most users from having full custody & portability of their accounts.
A permissionless blockchain does seem like it would be a suitable solution, but your identity page mentions avoiding blockchain due to slow commitment times:
> At present, none of the DID methods meet our standards fully. Many existing DID networks are permissionless blockchains which achieve the above goals but with relatively poor latency (ION takes roughly 20 minutes for commitment finality)
What latency is really needed for a global name registry of a social network? I've only registered a few Twitter handles in a 10 year period, and each time I would be OK waiting for 15-20 minutes (or longer) to ensure commitment finality if it means I could escape the centralized host at any point in the next several years. Similar story with rotating keys and updating any pointers to my host/server.
Nah thanks, I'll stick with ActivityPub. The fact they even felt the need to create another protocol instead of using, improving and contributing to ActivityPub makes me think they want to bake a busines modell for themselves into the technology and they can't do that if they don't have full control over the spec. ActivityPub is organically grown from a community to serve that community. Bluesky is created to combine…
'The specification may be terrible, and everything good about it may be implementation-specific, and every touted feature you're looking for may be missing from the only implementations anyone uses, but you can always just break compatibility from all the de facto standards, and so that's no reason to come up with your own base standard' seems flatly wrong, and that actually is a pretty great reason to come up with y…
I never was on Twitter, but I am a Mastodon and Pixelfed user. I have zero interest in the cesspool that is Twitter joining the Fediverse and if they did I would probably instance block them.
This is about standards and my suspicion, that they want to keep all the control and profits, but now want to call it federated.
> The specification may be terrible
Have you read it ? I haven't, but it is working pretty well for the Fediverse. And once again: Standards aren't static, if you actually have a concrete problem with the standard instead of a gut feeling, that "it just sucks, don't ask about the details", then formulate it and bring it up to the creators of the spec or try to fix it yourself.
> IRC beat the 'the standard is just fine as it is' drum for many years
Well maybe that is the difference between IRC and ActivityPub. Nobody on the ActivityPub side is delusional enough to think the standard is perfect. There can pretty much by definition never be a perfect standard. There will always be use-cases that were not thought of during the creation. The solution is not to create one standard after the next, it is to improve existing ones. 1000 Standards are as useful as no standard.
If a team can't work within an existing standards body or a community (like the ActivityPub contributors) then they simply can't create an actually decentralized and open protocol/network. They can, however, create something that they can define and control for their own gain. Rolling out this protocol on a site without a community forum or other discussion channel but simply a "give us your email address and we'll l…
Why does every new idea need to work within the constraints of ActivityPub and W3C? Their spec is fundamentally different than ActivityPub.
Great to see some more concrete ideas beginning to come out of this team! My main concern with the protocol design is in the identity, and how it lends itself to centralized name services (@alice.google.com). The end result seems like it will be no different than Mastodon and email protocol, where a few central players own the majority of the namespace and network effects prevent most users from having full custody &…
You are correct about Email, but Mastodon ? Instance diversity is alive and well.
People don't choose Mastodon servers by the number of users that are already on it, but by what domain name they would like to have in their identity name. People join the community they identify with ignoring "network effects".
Great to see some more concrete ideas beginning to come out of this team! My main concern with the protocol design is in the identity, and how it lends itself to centralized name services (@alice.google.com). The end result seems like it will be no different than Mastodon and email protocol, where a few central players own the majority of the namespace and network effects prevent most users from having full custody &…
> The end result seems like it will be no different than Mastodon and email protocol, where a few central players own the majority of the namespace and network effects prevent most users from having full custody & portability of their accounts. You are correct about Email, but Mastodon ? Instance diversity is alive and well. People don't choose Mastodon servers by the number of users that are already on it, but by wh…
Network effects dictates that most of the time you will just stick to the same domain you signed up with, because you don't want to lose all your DMs and posts, and you don't want to start over again with a new name.
Earlier quoted context omitted.
that's an interesting question, I think spam is part of how... for a proper answer I would look at how SMTP has evolved over time.
SMTP started without proper authentication so anyone could spoof anyone's address. Most of those extensions try to fix this. But ActivityPub, for example, has authentication built-in from the beginning in the form of HTTP signatures.