It's decentralised as in federation. There is no central host, only instances that users can pick from (or self host). And to make it more than just a self hosted service, those instance hosts can link their networks together and allow users to interact across the greater web of federated instances.
So it's decentralised in the sense that Mastodon or Matrix are.
If the identity is based on a cryptographic key, I assume you can move your account to a different server? Even without help from the original server. But not sure how easy to move the contacts in that case.
Decentralized doesn't mean peer to peer. It merely means that there's no central provider -- for example, e-mail is decentralized, while Discord isn't.
Distributed would be peer-to-peer. Decentralized can be client-to-node with no central node. A lot of people use these terms interchangeably and call distributed systems decentralized since distributed systems have no centralization either, but this system with federation is also a valid decentralized system
This project doesn't currently use a protocol besides http. It is mainly a rest api for the efficient event driven merging of multiple server side databases into a single client database.
The initial motivation for this project (beyond wanting a sense of privacy) was not finding any chat service capable of running on low cost CE devices. To me this is critical for reaching an audience beyond tech enthusiasts.
If this project continues to mature I could see it valuable to implement the XMPP or ActivityPub protocol, but I am not yet sure what that would mean. If it were to affect the execution requirements, then it should be implemented as a separate module with hooks into the core service.
Wanted to ask the same. For any new decentralized service, my first question is this and if not whether they've thought through why/why not.
There are many legitimate reasons why someone might not, but if they've not thought through them and whether or not they could achieve the same with extensions to ActivityPub I'm instantly sceptical.
From a very quick look, the key-based identity might be what would require protocol-forking for Matrix and Pleroma chat, and non-trivial extension for XMPP, and thereby be the motivating factor of making a non-compatible protocol.
The motivation for the project was mostly trying to see if a chat service could be run on low cost hardware, hence the reason for targeting RPi Zero.
I would love to see other federated services running on home CE devices, but I don't see this happening with the execution requirements of services like mastodon or matrix. While those services are great and I use them, I think they lend themselves more to group hosting vs personal hosting.
There's nothing in the ActivityPub spec that is particularly heavy. Mastodon is pretty much the heaviest possible ActivityPub option. If you want to handle just an individual account and especially if you want to handle mainly messenger style direct messages, you can do that with far lower requirements.
It imposes some limits, but they're pretty basic. Mastodon then adds a few more things. E.g. @vidar@galaxybound.com is my Mastodon handle, but that resolves to an ActivityPub actor via webfinger [1]. The ActivityPub actor is at [2].
Basically ActivityPub sets out a very basic skeleton for passing messages ("activities") between actors designated by URI's. Those messages must be JSON and has a few very basic requirements, such as having a "type". E.g. "Announce" is a type that corresponds to "boost" or "retweet", "Create" is a type that means you're creating another object such as a "Note" (toot/tweet) which follows the same general structure.
Those messages can be addressed to specific other URI's representing audiences with to/cc fields. When you add that to your outbox, you or your instance also need to post them to your followers instances.
So as long as you can receive POST's w/JSON, and return a list of JSON versions of messages, you have the basics. The JSON in ActivityPub is verbose but it's not very hard to generate, so bridging is likely doable.
28 comments
[ 4.1 ms ] story [ 75.4 ms ] threadSo it's decentralised in the sense that Mastodon or Matrix are.
The initial motivation for this project (beyond wanting a sense of privacy) was not finding any chat service capable of running on low cost CE devices. To me this is critical for reaching an audience beyond tech enthusiasts.
If this project continues to mature I could see it valuable to implement the XMPP or ActivityPub protocol, but I am not yet sure what that would mean. If it were to affect the execution requirements, then it should be implemented as a separate module with hooks into the core service.
But is the vision to be able to “DM” with users on instances of mastodon, Lemmy, etc?? (anything that supports activity pub)
There are many legitimate reasons why someone might not, but if they've not thought through them and whether or not they could achieve the same with extensions to ActivityPub I'm instantly sceptical.
I would love to see other federated services running on home CE devices, but I don't see this happening with the execution requirements of services like mastodon or matrix. While those services are great and I use them, I think they lend themselves more to group hosting vs personal hosting.
Basically ActivityPub sets out a very basic skeleton for passing messages ("activities") between actors designated by URI's. Those messages must be JSON and has a few very basic requirements, such as having a "type". E.g. "Announce" is a type that corresponds to "boost" or "retweet", "Create" is a type that means you're creating another object such as a "Note" (toot/tweet) which follows the same general structure.
Those messages can be addressed to specific other URI's representing audiences with to/cc fields. When you add that to your outbox, you or your instance also need to post them to your followers instances.
So as long as you can receive POST's w/JSON, and return a list of JSON versions of messages, you have the basics. The JSON in ActivityPub is verbose but it's not very hard to generate, so bridging is likely doable.
[1] https://webfinger.net/lookup/?resource=vidar%40galaxybound.c...
[2] https://m.galaxybound.com/users/vidar but needs Accept: header: curl -H "Accept: application/activity+json" https://m.galaxybound.com/users/vidar | jq .