Live data from Hacker News

ActivityPub: decentralized social networking protocol

w3.org

61–70 of 140 posts

Re: ActivityPub: decentralized social networking protocol

#61
ActivityPub is like JWT. Simple on the outside but complex inside. For example I wanted to implement a simple server to connect to Mastodon. JSON via HTTP, what could be simpler? Actually it's JSON-LD not JSON. But it doesn't matter as JSON-LD is JSON, right? No, as the standard requires normalizing JSON-LD for purposes of signing that includes all of RDF canonicalization, of course the standard do not require it [0] but it's akin to unencrypted HTTP2, theoretically it exists but practically doesn't.

What's interesting is that ActivityPub requires signing the data twice, first on a HTTP request level, then the JSON-LD itself. It seems like the designers tried to make it simple (let's use JSON-LD and HTTP) but after several edge cases the standard got out of control.

[0]: "Linked Data Notifications also supports a number of RDF serializations which are not required for ActivityPub implementations. However, ActivityPub implementations which wish to be more broadly compatible with Linked Data Notifications implementations may wish to support other RDF representations." source: https://www.w3.org/TR/activitypub/

Re: ActivityPub: decentralized social networking protocol

#62
post #52
post #48

Earlier quoted context omitted.

That's not true. XMPP can do far more than instant messaging, and it's definitely not complicated (well for a decentralized network and for technical audience of course). For the record I'm the main developer of a XMPP based "social network" project (Salut à Toi), and we are able to communicate natively with others XMPP projects (e.g. Movim) for years (we can share comments like in the video, it's the basis of common…

The problem I've always had with XMPP is that any time I try to do something with it, I get lost in an endless sea of RFCs with no idea of which are important for my use-case (most RFC titles seem fairly jargon-heavy to me). Then, when I go to read an actual RFC, because of the fact that each RFC has some interactions with all other RFCs, they're fairly impenetrable. Is there a document somewhere collecting the most…

I'd recommend looking at the Compliance Suites which were designed to address this (disclaimer: I've been the author for the last few years, although I just transitioned out of that role):

https://xmpp.org/extensions/xep-0387.html

I know there's a big scary "Rejected" warning at the top, but in this case it's okay to disregard that. It was rejected for bike-sheddy reasons about it not being perfect yet and is still a good starting place. The warning should go away sometime in the next few weeks (the problems that it was rejected for have been addressed, so the next time the council meets it will likely be accepted).

Re: ActivityPub: decentralized social networking protocol

#65
post #7

From my quick read of the spec, server-to-server federation assumes that servers can be trusted. That need not be the case; unless a message is signed it should not be assumed to have come from a specific user. I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). The other question is whether we want server-to-server federatio…

It's intended that server-to-server messages be signed with the private key that matches the public key baked into the user's profile data. I'm not sure whether the final specification requires this, or merely recommends it; it may have gotten pushed off to a future update in order to get the spec out on time.

Re: ActivityPub: decentralized social networking protocol

#66
post #46
post #17

Earlier quoted context omitted.

> I don't know if there's an easy way to share keys in a decentralized way, but that'd be an interesting problem to solve (some blockchain maybe). This is exactly what namecoin tried to solve. Buy an identifier, put whatever you want in it. Example: https://nameid.org/?name=rakoo > The other question is whether we want server-to-server federation at all instead of a P2P network like bittorrent. We want something in b…

Scuttlebut is, so far, the most interesting decentralized social media tool I've seen. Even Mastodon and Matrix still require a server of some form, while SSB will continue to work offline and via truly local peer to peer connections. The only issue is client support and the fact that I don't have a good sense of the state of development/stability/soundness for SSB. If you (or anyone) has experience actually using SS…

SSB is rock-solid in that the community encourages the use of diverse client and server implementations rather than having a monolithic interface that's meant to do everything.

On the other hand, the underlying libraries are opinionated in that they usually use depject and a handful of other tools/techniques that aren't super familiar to those outside the SSB community, which makes it harder to write brand new clients.

I'd use SSB exclusively if they offered a web client (as I'm on a Chromebook), but we're slowly getting there.

Re: ActivityPub: decentralized social networking protocol

#67

Earlier quoted context omitted.

Thanks! After reading that article I'm curious where public key cryptography fits into this.

In AP, messages are signed with http signatures ( https://tools.ietf.org/html/draft-cavage-http-signatures-09 ). OStatus has a similar mechanism called salmons, which are signed XML payloads.

server-to-server signatures are a good start, but what about encrypting messages end-to-end? I assume the servers already talk over HTTPS.

Re: ActivityPub: decentralized social networking protocol

#68
post #11

Earlier quoted context omitted.

As a counter example, there are millions of non-technical users using the bittorrent protocol. They are running a server on their machines and not aware of the technical complexity that lies underneath. I am not saying it's an easy UX problem to solve, but it can be done.

Sure, I think the problem with people running i.e. Mastodon on their own machine would be what should happen when people turn off their computer. I guess there could be some sort of "super node" solution, where a known Mastodon server would just forward you the "what happened while I was asleep" stuff and I guess people could encrypt their messages to you with your advertised public key, so that you don't have to tru…

That's basically how Secure Scuttlebut works; the super nodes are called pubs.

It's actually remarkably easy to onboard to SSB with Patchwork. The problems set in when you start considering mobile devices or multi-device support (the latter is currently possible but risky).

Re: ActivityPub: decentralized social networking protocol

#69
We need P2P not federated. Federated still requires trusting a server which is not good. We've tackled this problem and produced an insanely simple API for creating fully P2P apps, even the cliche Twitter/todo app can be built in 4min: https://scrimba.com/c/c2gBgt4

Re: ActivityPub: decentralized social networking protocol

#70

All of these social networking protocols feel like we're just re-inventing UUCP at a higher level.

I've considered that, as well. I enjoy Mastodon, and am working on another ActivityPub project. But in a lot of ways it's not a significant advantage over Usenet.
Post reply on HN