Public post federation

@jonnehass yeah I have no real grasp of the D* protocol so I didn't mention too much about the specifics in the proposal, just the idea of the relay.

To me the central hub makes sense for a reliable source of network data. I mean we don't decentralize the project page and the wiki either - the central hub isn't any different from those resources.

Still, I also believe tag federation across pods would be a good feature for Diaspora…

I have a different way to solve this problem. I'll try to get a page on the wiki this weekend.

OK, alternative proposal here: https://wiki.diasporafoundation.org/Tag_aggregation

Let me know if I should start a new Loomio proposal. I'm new at this.

What advantages does this method have over the scheme I proposed in this thread (it talks about tag federation about half-way down).

I'm not a coder at all, so this is just a concept rather than anything more detailed, but I hope it might help to improve D*'s federation, especially for new and one-user pods.

@goob My concern with that approach is that it's very inefficient (it looks like O(n²⁾ for you computer science types where n is the number of pods; the amount of network traffic grows rapidly as the number of pods increases), and it implies that all pods are equally trustworthy sources of information about the podsphere.
Also it seems to me that your proposed solution would require a lot of new code to be developed, alongside new messaging semantics. This is based on a very quick analysis so I could be way off base here.

I'm trying for an incremental model that scales well with minimal new coding required. Also in my proposal tagged posts are federated in a very efficient model that scales linearly (O(n + m) where n is the number of posts and m is the number of pods).

Thanks for you reply. That sounds plausible (damnit!).

@Goob no damnit at all! I wouldn't have thought of using the pod to help locate other users or index other posts were it not for your proposal. There's probably a better idea out there than the one I proposed too; I just hope I can contribute something.

Great @bradkoehn ! And @goob all ideas are welcome - they all add to our ability to build the best solution.

There are many similarities regarding mine and Brad's idea - especially the part that relates to a central hub to store pod information. I really really am sure we need this, for many reasons. I'll put something in the wiki and separate this into it's own place since it is kinda separate though required by the public post federation/aggregation. Once we have a spec we'll just need to vote since I know some community members don't like this idea even if it is totally opt in :P

As for the idea from Brad, I'm quite sure it would do the job and would be happy if either idea was implemented. Initially I was questioning the idea of pull instead of push, but I guess the pubsubhubbub takes care of that problem (even though then we do rely on those external services, the default diaspora uses is from google).

I do think though that my relay server idea is lighter because there is no need to save posts. It also handles redundancy - pods are not tied to any particular aggregator and thus even if all but one of them are down the post will be delivered to all listeners.

Security I guess in both would be the same. Except I see some worry that an aggregator could be populated with non-authentic posts, and even if no pods accept the posts, some other source might do. Since the aggregator would have an open interface, it wouldn't take long for someone to build an app to show posts in the diaspora network going through the aggregator. In this situation it would be trivial to inject posts into the aggregator, unless the aggregator checks all of them. In the relay idea this is not a risk since the aggregator doesn't store posts.

Any other opinions on these ideas?