Hacker News Reader

Hacker News

Comment by half-kh-hacker | Hacker News Reader

Parent Full thread

half-kh-hacker

It's not so simple.

In order to federate an object you must:

- send requests with proper 'HTTP Signatures' (many AP nodes have strict enforcement here)

- which requires you to have an actor with an attached signing pubkey

- so you have to host the LD-JSON actor descriptor on another endpoint

- actors MUST have an attached inbox & outbox, your receive endpoint will need to sit at your actor's inbox (on POST). both of these are OrderedCollections of Activities

- and in order to be properly interoperable you will probably need to maintain follow relations & write an endpoint which can ACK/NAK follows, etc etc

View on HN

What do those "HTTP Signatures" do?

If admin of serverA decides to add serverB to the servers_i_talk_to array, they also ask serverB to give them a public key and from then on serverA only accepts messages from serverB if they are signed with the corresponding private key?

Is that so that serverB can change its IP without interrupting the communication with serverA?

The fediverse is (generally) an open federation, not a closed one like you're describing. There is no manually-curated list of instances that you federate with.

I would expect "Open Federation" does not mean you need to talk to every instance out there directly. But that it works like a web where messages are routed around. I could be wrong. But I would expect the "servers_i_talk_to" array is what the instances output at the "peers" endpoint:

https://fosstodon.org/api/v1/instance/peers

There's not really any routing, but you don't need to send posts to every instance, just every instance that has users following your instance's users.

Is that the peers list? Other instance where at least one user follows one user from the given instance?

Yep.

HTTP signatures ensure that you can't send a message and spoof the user/instance that it's coming from. Think of it like DKIM for AP.

They commonly include the specific actor who is interacting with the network (via the instance), so we can also achieve correct-side enforcement of blocks.

With "actor" you mean "user"?

Every user has their own private key?

Sure an actor is basically a user, there's usually an "instance actor" though too that does some other things but I don't think having one is required. Every actor has a private key but it's kept on the server, it's basically an implementation detail.

Strange that users have private keys. Is that kinda forward-looking, so that at some point those keys could be moved to the users themselves? So they can keep their identity, even if the owner of their instance becomes malicious?

no lol

Then why?

The private key is used in HTTP Signatures for authentication. The signature does not cover the body of the http request and is not stored or published. The http post contains an http headers that signs just a few other header fields. The signature is only valid for a short time.

There is an example here: <https://blog.joinmastodon.org/2018/06/how-to-implement-a-bas...>

Reply on news.ycombinator.com