Public post federation

Interesting. I was thinking to something like that but not with the relay servers.

Could you emphasize the interest of having a relay server and of having several ones (with random use for each post) ?

@loelousertranslato having many would mean that if a relay server is down, the posts still federate. After all these would be user hosted services, not commercial grady with 99,99% uptime guarantee.

If a pod cannot contact a relay it would just use another.

Also I think pods could easily check the origin of the post easily just by asking the originating pod for the hash and compare it to the one coming from the relay - to stop relays generating posts. Will add this to the proposal.

At first I was thinking that the central hub could be the relay…

If I understand it well the central hub server has to be on but not all the time : if it shut down for a few hours it would just delay the new tags and pods that are taken into account in the list… but the federation and sending of posts would still be ok because of the relay servers.

Yeah that is one part of the idea of separating the functionality of a central hub and relays.

Couldn’t the central hub hosting the pod list with tags be in the pods themselves. With keeping track of the latest version of the list and pushing it to all the connected pods (connected because users would have added a user/seed from them in an aspect) if their list is older and if the admin has authorized the kind of federation…

• This way all pods participating to this should with high probability (?) and rapidly be interconnected.

• This way the list of pods and followed tags should be repeated in each pods so that if some pods are shut down the system would still work fine…

Well IMHO we need to have some kind of central hub at some point. We already have a central hub called diasporafoundation.org for the project. We also have pod lists like podupti.me. Having an official central hub that would receive data from the pods themselves would have lots of benefits. Syncing everything everywhere is problematic. For example some podmin sets up a new pod - where would that pod send the subscription list to? All the pods? How, where would it get even one pod address?

The central hub could also be used to finally gather statistics from the network (opt in of course). For example pods could report their amount of local users and post counts and these statistics could be reported on the hub to see where the network is going.

• I guess that a new pod would have to connect to any big pods around to be part of the public post federation. But well yes it has to have the info of where to find another pods first (podupti, web search engine…).

• having the list in pods with close to close spread of last version of the list is not exclusive to having a central hub that can be implemented first.

-So the order for any pods would be : 1- use the hub if it is on. 2. If not, use its own list. 3. get the list from the hub if newer list in the hub. 4. send the list to any pods and the hub if its list is newer.

Well, I write “newer list” but I am not sure that a “newer list” is more complete. Not sure how to track for the most accurate and up to date list is. I am not familiar with syncing and all…

The central hub part feels just wrong, I need to think more about that part.

For the relay part, we can save the hash checking blabla, by not touching the Diaspora protocol message at all. It is signed by the author, thus there's no way for a relay to spam messages to the network, for the same reason it isn't possible right now. So we could just send messages like {"hashtags" :["#a", "#b", "c"], "diaspora_message": "xml in base64 blob ready to post to /receive/public"} to the relay server.