You might be having a bad day, but at least you didnt spend like a decade developing a social media protocol that was structurally incapable of DMs so you needed to make a whole second E2EE protocol
@fediversereport Thank you for sharing. It is exciting to see what is happening! I think your point at the end is really worth considering: is #Bluesky and the #ATProto interested in multiple apps or is it merely a vehicle for microblogging? I don't have technical background, but I suspect that the decentralization for BSKY is more for show than practice. Critique #ActivityPub all we like but I do think the commitment to platform diversity is there and is practiced.
There are problems here too. I suspect this is a fundamental issue that decentralised social media hasn’t taken seriously enough. It’s a bit like back and front end people not working together well. Protocol people can be inclined to underestimate the importance of what happens in the client, which IMO is where federation actually happens, as it’s there that platforms and UIs need to get stitched together.
Bluesky enthusiasts are stating that Bluesky has ”plans” to make ATProto universal and transfer it to W3C or the like. Well, there is no evidence that Bluesky wants to give up control or the protocol is going to be widely adopted after 5 years of development so forgive me being sceptical. The story is a bit different with ActivityPub.
@rolle agree. If they were serious about this, they would commit to participate in social web working group and to moving toward full federation with the rest of the #Fediverse, instead of scoffing at anyone who raises these points.
@youronlyone because the Fediverse still has an account hooked to a server and an admin can block that. You migrate, you lose your posts, and migration is not seamless across diff networks.
Nostr requires no account creation on any server, and the keypair you use works seemlessly across any clients or Nostr websites. Any post you make with Nostr relays through 8 or more (of over 2,000) relays. Even if one relay owner were to "block" your profile, it still flows out seamlessly through any other.
Ah, I love arguing about #ATProto with people who prefer ActivityPub/fediverse and know very little about ATProto, but have strong opinions about it… 🙃
The whole idea of BlueSky supporting nomadic identities but the rest of the ActivityPub (plus other stuff) Fediverse being unable to do so is such an oversold idea.
A new service using ActivityPub behind the scenes (and not the AT Protocol) can absolutely support nomadic identities, even if the service doesn't treat a whole website as the actor.
It will still use did:plc, same as AT Protocol (BlueSky), but once done so, an application that understands how to work with did:plc can dereference an actor based on the DID.
That said, an existing service will simply not be compatible with this idea, without changing how it operates.
@Plastic Paragraph @Sal Rahman Nomadic identity, as invented by @Mike Macgirvin 🖥️ in 2011 and first implemented in the Zot protocol from 2011 and the Friendica fork Red in 2012 and used by Hubzilla and the streams repository today, goes even further.
Its basic functionality is to keep at least one clone of your identity on another server.
On most Fediverse projects, e.g. Mastodon, your identity is in your account and thus bound to one specific server.
Hubzilla and (streams) put "identity containers" into your account, so-called channels. Your identity is not directly put into your account, but into one of these channels. The channel separates your identity, your connections, your posts, your settings, your files etc. etc. from your login credentials.
This makes two things possible. One, you can have multiple, completely separate identities (channels) on one and the same account, accessible through one and the same login.
Two, and here does nomadic identity come into play: A channel can be cloned to another server.
Such a clone is not a dumb copy like when you move from one Mastodon server to another Mastodon server. It's a real-time, bidirectional, live, hot backup. And it's fully identical to the main instance of your channel, down to the identity, at least as perceived by server applications that know nomadic identity. Anything that happens on the main instance is mirrored to all clones, and anything that happens on a clone is mirrored to the main instance and the other clones.
For example: The main instance of my channel is on hub.netzgemeinde.eu. Thus, my identity is jupiter_rowland@hub.netzgemeinde.eu.
I've got one clone on hub.hubzilla.de. Hubzilla and (streams) understand nomadic identity. They know that this clone is the same jupiter_rowland@hub.netzgemeinde.eu. Even if I should send something from my clone which I've actually done once when Netzgemeinde was acting up, Hubzilla and (streams) connections still perceive it as coming from jupiter_rowland@hub.netzgemeinde.eu.
The big advantage of this is resilience against server shutdowns. This is actually the very reason why Mike invented nomadic identity in the first place: He saw Mistpark/Friendica nodes disappearing into thin air upon short notice or spontaneously. He saw users lose everything from one day or hour or minute to the next and always have to start over from zero. And he knew that the only solution for this problem would be if a user's identity resided on multiple servers simultaneously.
Nomadic identity makes channels even resilient against the shutdown of the server that contains the main instance. You can always declare any clone the main instance. If you still have a main instance, it's demoted to clone. All of your connections on Hubzilla and (streams) are automatically changed accordingly. The only difference in practice between the main instance and a clone is that the main instance is the one that defines the identity.
A byproduct of nomadic identity is that it provides the best way to move an identity from one server to another. It first creates a clone. Then it declares the clone the new main instance, turning the old instance into a clone. Then it deletes the old instance. If the account on the old server doesn't hold any more channels, the whole account is deleted.
So not only can you move with actually absolutely everything, a Mastodon user's wet dream that will probably never come true, but you can do so with relative ease and quite safely, and most of all, you don't leave a dead identity/account behind.
Okay woah, this is on a whole new level. Been trying Friendica and Hubzilla, but seems a bit over the pay grade in terms of complexity. And oddly enough, not too many intro/how to videos of them on youtube either...
Will have to do some further reading, as these two don't seem to be as user friendly as the normal Fediverse apps. And those were already a mind-shift when coming from traditional social media.
(I don't know what's the status of the "10 users" limit, at least the Bridgy PDS got it lifted, but even if it's not announced yet I think it's also going away / or will be relaxed soon)
@fediversereport I say no (to me it has to use ActvityPub to be the Fediverse) but classify it as other federated social media. I don’t see it taking off like Threads. See the Skygaze announcement.
Man, having access to the #Bluesky#ATProto API is like being at a really cool hackathon 24/7, just without the loud music and the noise from the open space… I'm getting ideas faster than I can implement them, I missed this kind of excitement for years 🧑🏻💻💙
“Blacksky is providing a platform to amplify, protect, and moderate Black content so users can safely build community online.
“The mission and purpose of the project is to de-center whiteness as the default and to provide a space for Black folk to discuss the Black everyday in a way that feels affirming.”