I’ve been thinking about this for a while…
At the moment, the invitation links provided within a pod are always to that same pod, which kind of goes against the distributed philosophy behind Diaspora.
Now we have a good project site which contains instructions for choosing and signing up to a pod, it would be really good to use this facility to help get away from pod-specific invitations, so that a user can invite a friend, who then is taken to our project site, chooses their own pod, and once they sign up there, no matter which pod they choose, they will be linked to the seed of the person who sent them the invitation.
What I’m thinking is something along these lines:
- the invitation link takes the recipient to diasporafoundation.org
- it prompts a cookie to be stored on diasporafoundation.org, which contains a link to the seed of the person who sent the invitation
- the recipient goes through the process of choosing a pod, using the information on diasporafoundation.org
- when they then sign up to a pod, the pod retrieves the information from the cookie and automatically connects the new seed to the seed of the person who sent the invitation
- the cookie is then deleted, so if someone else later used this service on the same browser, it wouldn’t confuse the issue.
This comes with the usual caveats about me not really understanding how the technical side of things work.
It might be that we can use something from David Morley’s dia.so service, which enables links which work across all pods. He’s obviously worked out some of the technical hurdles in implementing such a system, so some of the code used for that might work here.
What think you?
Note: This discussion was imported from Loomio. Click here to view the original discussion.
Although it’s a good idea to try to have a more decentralized way to invite people, I can see two problems here.
The first one is that we often want to invite people on our pod. I create my pod to host me and my friend, so I want them to be on my pod, because I trust me and not the other podmins
The second one is that we don’t want anything to depend from a central point like diasporafoundation.org. With your system, if diasporafoundation.org is down, the invitation system does not work anymore. That’s a weakness that we want to avoid.
I’d just have a “put me on a random pod” button on our project site - much simpler and does the same thing
(of course we first need a pod list and unfortunately didn’t seem to be much enthusiasm there when I suggested it)
I think it would make sense for the links go to the pod where the invitations were sent from.
so if you invite someone from your pod the link in the invite would go to your pod
(or am I missing something? - I guess it could be made a config option if some people want something different?)
yeah a pod list (voluntary) would be nice too
(voluntary listing for any pod with open rego offering to take on some new users - I guess the hard part is probably deciding how it would be moderated and kept up-to-date)
Michael, we already have pod lists that are either manually maintained (http://podupti.me) or semi-automatically maintained via a single pod data (http://diapod.net/active). Both these are “unofficial” and in no way tied to proper mechanisms in the D* code.
IMHO, we need a central pod database (opt-in) to use for programmatical situations, for example randomizing a pod to new users (not invite imho).
I agree I don’t like having to rely on a central site for the mechanics of a pod to work. However couldn’t there be an option set to choose either system? Either select to use Goob’s Diasporafoundation idea or use the traditional invitation system. Pods that opt for the former could be worked into a database on the DF’s site, pod’s that opt for the later could operate how they’ve always done or be worked into a different database. The name of the game is choice.
do like this, a pod can set stus like sign up available. when its set or cleared its communicated to other pods. if a pod is overflowing with users (sign up ia not available in it) it randomly selects a pod that has a sign up and redirects users to it.