| Thanks, will look through these. But all of the ones I have looked at so far seem pretty complex with hundreds of files. I don't know the fediverse protocol yet, but I would hope I can get away with just two files like this: receive.php <?php
if (!isset(servers_i_talk_to[$_SERVER['REMOTE_ADDR']]) die();
$data = $_POST['msg']
$file = 'log/' + time().'-'.mt_rand();
file_put_contents($file, $data);
send.php <?php
$data=$_POST['data'];
for ($servers_i_talk_to as $server) {
$url = "https://$server/receive.php";
$msg = ['msg'=>$data];
$opts = [
'http' => [
'header' => "Content-type: application/x-www-form-urlencoded\r\n",
'method' => 'POST',
'content' => http_build_query($msg)
]
];
$context = stream_context_create($opts);
file_get_contents($url, false, $context);
}
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. |
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