@bradkoehn That is why I suggest the hub is configurable already.

The MEAN stack is not something new or unknown - it is or at least the components used are becoming very popular. Node is HUGE and really the best tool for things like this, imho. Constantly someone is saying "I would participate but Ruby..." so I don't think the answer is to just build everything in one language. Ruby is also very resource hungry compared to a pure javascript implementation. There is a reason that Diaspora is made in rails - there is no reason the hub needs to be ;) Also there is no reason to not use something like MariaDB instead of Mongo.

Anyway, technical details can be decided on separately, that was just a suggestion. The main thing is to agree (or not agree) on the need for this.

But if it's in Ruby I cannot do it since it would take too much time - I don't have that much interest to learn more Ruby than I need since I want to concentrate on Python and JavaScript. I'll still offer to host it :)

This idea just flies in the face of the decentralized nature of D*, it seems.

@ram518 how?

couldnt much of this be done with an API (in the works, or so ive heard?) in that any one, or any server could ping any or all known pod's API to get this information, provided the admin has allowed this feature to be enabled? This would allow continued federation of information, and the option of a hidden pod or simply a pod tha has decided to opt out for privacy reasons.

@jacobschleappi how would you know what pods to ping?
Also this proposal does not force anyone anything - please read the "opt-in" in the proposal mentioned many times.

Isn't the proposal a bit "fat"? Pods can't query unknown pods directly for obvious reasons; to address this, much less work is required: one only needs to let pods "register" with any number of trackers and ship the Diaspora server code with a customisable list of such trackers. Everything else can then be negotiated pod to pod.

A tracker doesn't need to store anything about a pod except for the hostname and the time of last ping (to allow for record expiry).

About pod registration: your proposal says this:

/register Pods will call with this initially when they want to register the pod. This call will be followed by the central hub calling back to check the pod is really a pod.

How would the hub be able to ensure that a) the party issuing the registration is a pod and b) speaks on behalf of the registered pod? Re a: is it a problem if a registering client behaves like a pod but is not? Re b: it should not be possible to register a pod you don't control. To demonstrate control, the creation of a DNS text record with a token could be sufficient to solve this problem.

This brings me to the next question: if this all only works for Diaspora pods and requires explicit consent --- why use REST? Pods are capable of much more complex communication than simple HTTP requests (e.g. stateless vs stateful).

@rekado I think you (and everyone else who has commented) are missing the (main) point of the whole system - to gather metrics on the diaspora network. And in metrics it's not just about pods - it's about users. We cannot have reliable statistics towards the outside world without a reliable way of collecting them (from participating opt-in pods). Listing pods is another thing, collecting user counts is another.
Yes we could do as you say and have a gazillion of trackers. You can call this hub I propose a tracker because that is what it would be. I'm happy to have many trackers - but I don't see how that makes the system any better.

I'm going to create a vote on the public metrics thing - I should have started there. Clearly proposing something technical only made sure to hide the whole point of the proposal, eg the end result.

On the other questions;

How would the hub be able to ensure that a) the party issuing the registration is a pod and b) speaks on behalf of the registered pod?

Simple - it doesn't save the pod until it calls back. If the pod "speaks pod" - it's a pod. If it replies "wtf I don't want to be registered go away" - then clearly it did not make a request. This is the same way "verify your account by clicking the link in the email" works to ensure ownership (well, other direction, but same principle).

To demonstrate control, the creation of a DNS text record with a token could be sufficient to solve this problem.

We're gathering statistics, not solving privacy or authentication issues - no need to shoot a fly with a cannon :) Making pod admins have to modify their DNS just to register is a bit too much imho. But of course, the way I indicated was only an example - it would be nicer to agree on whether this thing is needed.

if this all only works for Diaspora pods and requires explicit consent — why use REST? Pods are capable of much more complex communication than simple HTTP requests (e.g. stateless vs stateful).

What would that achieve that a simple POST/GET would not? To be honest, I'd agree to anything, the end result is the most important. I just don't see the point of building complicated things to make something simple. We should leave the complicated things for the important stuff, eg Diaspora itself.