Before you go to the trouble of writing your own software, consider using one that's already been written. There are many[0] out there already besides Mastodon.
Where receive.php is openly accessible and send.php is protected by a password.
The endpoints are surely called differently than receive.php and send.php. But this is how I would hope ActivityPub works in principle.
Of course, this would be very bare. To read, I would have to read the raw log of ActivityPub messages and to post, I would have to manualy put together an ActivityPub message.
But I would be in the Fediverse and could add more convenience functionality later.
- 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
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:
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.
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.
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.
I don't know the fediverse protocol yet, but I would hope I can get away with just two files like this:
receive.php
send.php Where receive.php is openly accessible and send.php is protected by a password.The endpoints are surely called differently than receive.php and send.php. But this is how I would hope ActivityPub works in principle.
Of course, this would be very bare. To read, I would have to read the raw log of ActivityPub messages and to post, I would have to manualy put together an ActivityPub message.
But I would be in the Fediverse and could add more convenience functionality later.