Loomio
Sat 16 Nov 2013 12:53PM

Central hub

JR Jason Robinson Public Seen by 122

Here is my proposal to create a central (opt-in) hub of information relating to pods in our little social network. Please read the full proposal before judging it ;)

I would like to vote on this as soon as all constructive comments relating to technical specifications is processed. I am prepared to code it and host it (until official servers exist).

Full proposal here: https://wiki.diasporafoundation.org/Central_hub

Ps. I created this in the main community group, not a subgroup, since I think this is something that all community members should be allowed to vote on without having to hassle with requesting subgroup rights.

EK

Emmanouel Kapernaros Sat 16 Nov 2013 1:16PM

Sorry if my comment is wrong because I may have not completely understand your proposal although I have read the wiki about the central hub and relays.

I have to tell you that, as I see it, diasporafoundation.org or github repository (which are central hubs in a way) are not the same..

For example if diasporafoundation.org is down, I dont care :P nothing bad happens to my pod. If github close for ever, I dont care either, because the source code is not dependent on github.. git is decentralized..

But if the central hub you are proposing is down, then we have a problem. One of the reasons diaspora is better is because it is not dependent on a central mashine.

From diasporafoundation.org:
What is decentralization?

diaspora* is completely different from most networks that you use. It is completely decentralized, with no central “hub”. Even so, it’s very easy to connect and communicate with people. Here’s how.

JR

Jason Robinson Sat 16 Nov 2013 1:20PM

@emmanouelkapernaro the central hub should not be required for a pod to run - so your pod would not be affected in any way if the central hub is down or disappears.

Some services which use it might be affected - but pods would not be affected in any way. Please read the proposal carefully :)

JR

Jason Robinson Sat 16 Nov 2013 1:22PM

Maybe calling it a "hub" was wrong and confusing :P Infostore? Register? :)

EK

Emmanouel Kapernaros Sat 16 Nov 2013 1:22PM

Yes, I understand this. If the central hub is down the my pod stops having public tags federation.. How this is not affecting my pod in any way?

JR

Jason Robinson Sat 16 Nov 2013 1:25PM

@emmanouelkapernaro actually if you read the proposal for relays carefully, the central hub is not needed since pods would cache a list of relays. Anyway, that proposal does not relate to the hub directly - these are separate things. The relay is not even the only proposal concerning public posts.

Is your pod affected now by missing public post federation? I think it might be affected :)

EK

Emmanouel Kapernaros Sat 16 Nov 2013 1:45PM

@jasonrobinson public post federation now is a missing feature. It affects my pod, yes. I dont want to have something new that also affects my pod, thats why I prefer not to have anything centralized.

So, to understand better your proposal, the central hub is only needed just to hold as much information about what pods are out there and helping them get in touch by distributing this info openly, right? Like podupti.me but more useful for features like federation.

If this is correct, then why not thinking about a decentralized method of distributing information? I am not an expert but isn't that what DHT is for? Am I too wrong here?

BK

Brad Koehn Sat 16 Nov 2013 1:52PM

What happens if different pods use different hubs? Can pods use multiple hubs? Is there anything good or bad there?

Also, are the pods listed in the hub ("directory" might be a better term) curated in any way against bad actors (e.g., a pod that is spamming)? I understand that the hub doesn't move messages on its own, but I'm trying to get at the policy implications.

JR

Jason Robinson Sat 16 Nov 2013 2:34PM

@emmanouelkapernaro because making a decentralized way of providing information on the network would be overkill. If one morning, until someone installs a new hub (imagine the data center is wiped off the earth) and restores a backup, you will not be able to see how many pods or users the diaspora network has - will that affect anyone at all? No, because the hub (or directory) should not contain any information that stops pods from working without it. That is stated in the proposal :)

Whatever system we would make to sync all the information to all pods for this requirement would just overkill. When building software one was meet the needs as is required, not spend time on building stuff that doesn't offer enough benefit concerning the effort that goes into it (imho at least). It's not like we're overflowing with developers and we don't have anything to do ;)

So my question back is - what would be the real benefit from decentralizing opt-in information concerning the diaspora* network as a whole? A real use case or just because it's possible? ;)

Also I think you're missing the main addition by this - information. The main benefit is information on the network towards the rest of the internet. To show that diaspora* is not a dead project. To show the network is growing. To prove to ourselves the network is growing :)

@bradkoehn Similarly I don't really see the point for multiple hubs - the benefit is really small. The code would be open source and if the data is open - any disaster to the hub would just involve someone reassign the subdomain IP and setting up a new hub.
But then again, I don't think there is any reason to not include the hub address in configuration. Maybe multiple hubs are needed when we have 1 million pods, then they would just need to sync up together ;)

As for spamming, the hub collects the information, it doesn't take information. If someone goes through the effort to customize their pod to give wrong information or makes a dummy pod that talks like a pod - I'm sure those cases can be dealt with quite quickly with some manual admin work. The important part is that the hub calls the pods for info, not the other way around.

I'll add this to the proposal;
- End point to get the full data export from the hub (just a static link to an archive updated daily for example - this should of course not be abused). In a disaster case this export would be imported to a new hub. Thus no one needs to trust the server admin.

Also please remember this is just a suggestion and a draft, please feel free to suggest on changes. And btw, some resources we have centralized would really hurt the network. Like the wiki - if that just disappears we will not have any new pods up since no one will know how to set one up. Would be really nice to have the articles synced somewhere :P

JR

Jason Robinson Sat 16 Nov 2013 2:41PM

Oh yeah, I forgot my original idea that pods could optionally hide some of the dataset. For example some pod might not want to report the amount of users but would want to register to the hub (directory).

I'll add this too.

BK

Brad Koehn Sat 16 Nov 2013 2:59PM

@jasonrobinson There are many benefits to having multiple servers; we allow pods to configure ther services they want to use (like Google's Pubsubhubbub provider) in case they want to isolate themselves from another group of pods, or simply prefer another provider's services. All centralized services should be selectable by configuring the pod.

Once you get into the business of curating the pod list, the ability to support multiple servers is critical.

I'm not sure I like using a different stack for the reference implementation; if everybody who implements a centralized service does it in the stack of their choice we'll soon turn into a hodgepodge of disparate server technologies. I guess the API is so small that somebody could whip out a new one with minimal effort, but a new developer now has to learn another stack or write a completely new implementation from the ground up. I don't think Mongo buys you anything you can't get from a normal RDBMS anyway (this is pretty much some REST APIs in front of a single table, right?); my guess is that it's a stack you already know more than the right stack for the team as a whole.

Load More