joindiaspora crisis

I read somewhere (can't find it now) that pump.io redirect to a random installation when you click on the "try it" button, so registrations should be spread out over all installations. They do this because they had the same problem with identi.ca. Something like this might be a solution.

@rogerbraun kinda like that idea - but first we need an actual pod list. I would prefer some app installed on a foundation server and opt-in configuration for open pods to "report home". Then we would have a reliable foundation controlled pod list that could be used for this kind of "load balance" purpose and in the future for other things.

One thing to do would be to contact all the sources online which talk about Diaspora and give the joindiaspora.com address, and ask them to change their link to diasporafoundtation.org. I saw another one last night.

Also, just as an anectote, I already had my own pod set up and still switched to joindiaspora.org. The reasons:

1. No tag following on other pods, which makes the ability to follow tags pretty useless on small, private-ish pods.

2. The impossibility to set up a free ssl cert for a subdomain. I already have my own domain and do not want to keep another one around just for my diaspora installation. Also, SSL certs are just an enourmous hassle to manage and keep up to date.

I do some monitoring of #diaspora tags on Twitter, G+ and Facebook :) Mostly it's not relating to our platform but the "other diaspora", but there is the occasional post about someone talking about Diaspora. I've been replying to quite a few correcting misunderstandings etc. It is quite obvious that many still think joindiaspora is the "official" Diaspora thing - though the changes on joindiaspora themselves should help with that since now it clearly mentions that it is only one pod. Some people still think Diaspora needs an invitation ;)

In the future it would be nice to somehow build up "pod neutral" social media accounts - for example the Twitter account used as the official one is actually the joindiaspora.com account which is confusing. But as it has tens of thousands of followers I don't think it's worth the hassle of changing accounts - and certainly we have better things to do..

Maybe Maxwell will get fed up with joindiaspora.com one day and he will sell it to a possible foundation ;) Then it could actually be an official foundation pod :P

In the future it would be nice to somehow build up “pod neutral” social media accounts - for example the Twitter account used as the official one is actually the joindiaspora.com account which is confusing. But as it has tens of thousands of followers I don't think it's worth the hassle of changing accounts - and certainly we have better things to do..

You can change a Twitter account name very easily and maintain all the followers - so it could be changed from @joindiaspora to @diasporafoundation or whatever.

@goob That's actually a really cool idea. I'd be all for giving it a name change in the future.

Should we start a new discussion to decide on a new name for the Twitter account? Hmmm..... scratches head for inspiration....

It's only a small minority that have the Amazon scare

thing.

@jasonrobinson I have noticed the Amazon scare thing but it touches on credibility for the Diaspora* values. There should be (are already?) certain guidelines for podmins that they then are recommended to follow. podupti.me monitors some of those possible recommendations such as SSL certificate status etc. However the transparency of hosting solution should be obvious for each and every podmin, especially since Diaspora* is listed on the User Data Manifesto:

1. Invulnerability of data

Everybody should be able to protect their own data

against surveillance and to federate their own data for

backups to prevent data loss or for any other reason. "

The joindiaspora.com pod does not follow that principle then if I have understood the surveillance of Amazon solutions. Ironically, Loom.io seems to be using Amazon in some way too.

Maybe I'm totally tired and off-track right now...

It's only a small minority that have the Amazon scare thing

I really don't think so. With all the PRISM story, people are afraid of the NSA etc. They want to use other tools. diaspora* is listed on prism-break. We have to indicate to them that joindiaspora is not prism safe!. There is no term of service, no indication nowhere that joindiaspora uses amazon. And that's bad. People have to know what they are using.

@flaburgan so you're saying not using Amazon makes something PRISM safe?

@openlifechallenge I'd like to see a place in the Diaspora values where it is mentioned that Diaspora is not recommended to be hosted on large corporation servers? No where it is mentioned. What is mentioned that "diaspora respects your data". The only way this is in fact done is to enable users to host their own pods and in essence hosting their own data.

Trusting another podmin is less secure than putting your data on Facebook - I'm willing to bet that for any pod out there..

Personally I think what we really need is to make it clear to people what Diaspora is and what it is not. It is not an answer to PRISM, for example - unless you host your own data.

Oh yeah and Loomio uses Amazon for sure as well. Why shouldn't they? Have they said they don't trust big corporations?

Imposing guidelines to podmins not to use large corporation servers would imho be wrong and against personal freedom of users to do what they want. It is dangerous to start restricting freedom of choice in the name of protecting peoples privacy ;) A nice golden line would be great - educating podmins for example.

so you're saying not using Amazon makes something PRISM safe?

Implication is different than equivalence :p Amazon => !prism-safe does not imply that !Amazon => prism-safe :p

Trusting another podmin is less secure than putting your data on Facebook

I strongly disagree there...

Oh yeah and Loomio uses Amazon for sure as well

Everything on loomio is public. Not comparison possible.

Imposing guidelines to podmins not to use large corporation servers

Who said that? It's totally fine to host a pod on heroku, on Windows Azure, where you want! The point is, users has to know that!. We all want more transparency in the world, this is the basics!

If a podmin is honest, he should tell that by registering on his pod, the data will be in [put the hosting place]. This is not done for joindiaspora, nowhere, and this is really a problem. @maxwellsalzberg I'd really want to heard you about that.

Personally I think what we really need is to make it clear to people what Diaspora is and what it is not. It is not an answer to PRISM, for example - unless you host your own data.

Strictly, it's only Prism-proof if you have your account on your own pod and don't share any content with anyone else on any pods, because as soon as you do that, your data (your posts at least, not your account data) will be stored on all the pods of your contacts.

I think as Diaspora is a Free Software project (and advertises as such) it would be good if podmins were discouraged from running Diaspora using any proprietary software as part of the 'package'. Obviously it's possible to install and run Diaspora on Mac OS, but that seems 'ok' in that the OS isn't really an integral part of the running of Diaspora. Hosting photos on Amazon servers seems a bit more problematic, although I can't quite put my finger on why, as again it's only a platform on which to do Diaspora stuff. I suppose it's this idea that your data are contained on your pod's server(s) - in this case, photo storage is outsourced.

I tend to agree with Jason that the answer is to have transparency rather than try to force podmins to make particular choices.

Either we collate information about resources each pod uses and put them somewhere obvious, or - better - there's a prominent link to the information for each pod on that pod's landing page.

It may be that for a certain pod, Amazon is the only economically viable option because they have so many photos to host, but on the other hand, it may be that when your pod has got to the size when you need to cope with such a large number of photos, your pod has simply got too big. This is probably the case for jd.com, and possibly one or two other pods as well.

I'm not sure that it's our place to tell Maxwell or any other podmin what choices they should and shouldn't be making. I think what we need to do is to get some good information out there, and encourage podmins to make such information prominent on their pods. We should also:

• design a new sign-up page which directs people to diasporafoundation.org if they're interested in signing up, so that if they've landed on that pod from e.g. a Google search or an invite email, they know they have a choice. The link to diasporafoundation.org would be a lot more prominent than the sign-up link.
• ask podmins also to place prominent link to diasporafoundation.org on their landing pages, with explanatory text that this is where to go before signing up to Diaspora
• work to get diasporafoundation.org at the top of Google (etc) search results, and joindiaspora.com and other individual pods down them. One way of doing this is to contact authors of articles which talk about Diaspora and link to jd.com and ask them to update/correct their link to df.org - Google ranks results largely by number of links to a site, so over time this will help. And this will help balance the numbers of people signing up to individual pods.
• make creation of some decent means of migrating accounts from one pod to another a top priority. I think we need to put together a working group of people who will devote some time each week to working on this, otherwise it could be another year or more before this is done.

Oh, one other thought - I wonder whether it might be possible for podupti.me to note any out-sourced resources used by a pod, perhaps in the tool-tip over the pod's name. Use of out-sourced resources (particularly non-free ones) could count against that pod's ranking. @davidmorley , does that sound possible/desirable?

I note that the two pods I use, pod.orkz.net and diaspora-fr.org, both use Google APIs, so it's not just jd.com which uses commercial/non-free resources.

@flaburgan so I'm dishonest for not stating where my pod data is hosted at?

Btw, where is it said that Diaspora is a "Free Software" project? :P

Let's not chase away potential users by ramming Free Software ideals down their throats. Unobtrusive education is the key.

Personally I sincerely hope Diaspora does not try to become a Free Software project. If that happens I don't really see it ever growing further than a little geeky experiment.. We need diversity, not ideological lock-in, however good the ideology is.

diaspora-fr.org, both use Google APIs

Oo @goob where did you see that? I never put any Google services on my pod, so if it's there, it's from the diaspora source code itself (you are talking about the inclusion of jquery?)

@jasonrobinson AGPL => diaspora itself is a free software project. But that doesn't mean every tools we use are free softwares. And don't get me wrong, being dishonest is about hiding something. I guess if someone asks you, you'll answer. But having this information clearly displayed is very important to me, and I really think I'm not alone.

@flaburgan I'm sure if someone had asked joindiaspora.com people too they would have said "Yes, we host on Amazon". So why do they get crap thrown at them but I dont? My host also is a commercial one, tries to make money and who knows who they send data to.

Also licensing something as AGPL does not make it a Free Software project. If we are in doubt whether Diaspora should official try to stick to Free Software principles - we should probably discuss that, vote on it and only then include it in our ideals. Until then AFAICT Diaspora is just a software project licensed as AGPL :)

The fact that Diaspora has the readiness for Facebook, Google Analytics, etc pretty much would make Stallman shoot the project with a huge bazooka instead of being excited about it being called Free Software.

Btw, where is it said that Diaspora is a “Free Software” project?

https://diasporafoundation.org/get_involved (and I'm pretty sure it's been in press releases and other documentation since the early days, although I'm not going to go back and check).

By the way, in the spirit of providing solutions rather than just complaining about a problem, what cost-effective CDN/hosting services are there out there which might be suitable for podmins of larger pods?

OK - still AGPL doesn't say anything about using large commercial providers. Free Software by definition doesn't say anything about this, except of course you find a definition like that (Stallman's maybe). Personally I really think we should not try to control what users (podmins) use the software for. That is the whole point of freedom.

Have found out that Diaspora is signed up to the User Data Manifesto, and points 2, 4, 6 and 8 on that manifesto are germane to this issue. Point 3 is essential to be solved, of course.

@jasonrobinson - diaspora is licensed as free software and is free software in people's minds, and that is important. how we go about making that known to people is another question.

If we're discussing joindiaspora, who is now maintaining it (is it under the control of the community/'diaspora foundation'?). If it is, one option would be the recent pump.io example (new users get automatically and randomly) redirected to one of 10 different installations. That could be the case for joindiaspora registrants too (it doesn't need to get any bigger) and would make it easier to maintain as well. It could also redirect people to podupti.me, but non-techie users might find that a bit daunting...

@goob - gandi.net and the redhat hosting, openshift (which offers a small free service) are both free software committed hosting services, and both big enough to be relatively cheap as well

@nickdowson joindiaspora is a private pod - as all other pods. There are no Foundation controlled pods yet - since we lack a foundation :)

@jasonrobinson well if that's the case there's not really anything we can do about joindiaspora so there's not that much point talking about it!

@nickdowson Discussion can always happen :) But as suggested by several people we can improve the way we "forward" new users to pods from our project website.

I also made up my account on joindiaspora.com just because of my lack of knowledge how diaspora works..
I was a bit confused.. and just decided for jd.com because I heard most about it and it had most users..
I guess lots of people did it my way .. and the major problem now: no way of migration to another pod..

So I think it’s crucial what Goob said:

“make creation of some decent means of migrating accounts from one pod to another a top priority. I think we need to put together a working group of people who will devote some time each week to working on this, otherwise it could be another year or more before this is done.”

This possibility, of transferring to a new pod, would initiate a self dynamic of more balanced resources!

The idea of a interactive map with all the pods + capacity notice also sounds great.. maybe even with a recommendation for which pod would be best resp. nearest to the user.. but as I just see, the frontpage of diasporafoundation.org is already pretty good, and explaining the decentralization! Maybe jd.com should have the same well explained frontpage like df.org and should refer to podupti.me

btw: jd.com is not listet @ podupti.me anymore, good choice!

I also think the suggestion of replacing joindiaspora.com with diasporafoundation.org on a lot of relevant sites would help for the balance..
I could do a research of mail contacts for this purpose? I could also write a template letter, but a native speaker should review that.. Finally it should be sent by a known @diasporafoundation.com address for credibility.

@cyclux that sounds great, if you can make such research we could send out the correction requests from the press@ account we now have.

Also @maxwellsalzberg as you have now requested that jd.com be transferred to FSSN for community management (no one has opposed so it's likely to pass) - any chance of closing the registrations? If the pod is overloaded as has been said - you probably know best how it has been running.

+1 for closing registrations and referring to Pod Uptime. Though, in the long term, we may want to come up with an API of some sort for reporting to Pod Uptime whether a pod is open for registrations or not. Would make it much easier for prospective users to disperse evenly amongst community pods if they didn't want to set up their own.

@seantilleycommunit joindiaspora.com landing page already links to podupti.me - though it could be made clearer maybe.

Would be great if podupti.me could be changed a bit to suit hosting by the general community under an official project asset status at some point. Then all we need is opt-in reporting from pods as mentioned a few times before. Bingo, we have statistics about our network. Of course all the data should be available openly via a restful API for transparency.

@jasonrobinson Alright, I do it! Will let you know here, when I'm done..

As Maxwell has talked on the other thread about handing jd.com over to the community, should we have a vote now about closing registrations and having a clear explanation and redirection on the landing page?

So, here is a short list of my research: http://pastebin.com/3cWbmgUt there are not so much “big” pages, that refer falsely to jd.com .. maybe also not every page is detectable with search engines.. but we should write the ones I found .. the best alternative option would be to look for the “referring statistics” of jd.com this would be the easiest way to really know which pages are linking to the site and especially have a lot clicks.. but anyway the next best step would be, to update the landing page of jd.com!

I like the way you're thinking about this. :)

A few directions I'd like to see this project take:

1. Add forks, not features. Want something in DIASPORA? Fork the project and make it work. If we like it, we'll merge it in. But I'm really getting tired of having 20 feature requests for every capable developer on this project.

2. DIASPORA is not JoinDIASPORA. The homepage of http://joindiaspora.com should emphasize that you should be running your own pod, or at least using one hosted by people you know in real life. We could link to http://podupti.me or the upcoming DiasporaProvisioner too, which automatically builds the latest Diaspora on your own Heroku instance, so that people are given very clear choices on how the network operates. We still will keep around the login/signup buttons, so people can still use http://joindiaspora.com. I almost want to make this reference pod a "trial" area for people, where they can register an account and see how it "feels" to use Diaspora.

I think whatever we decide to do, we should emphasize people checking out podupti.me and diaspora_provisioner before trying to get on joindiaspora. We should assume that once a user is on JD, they will never see the usefulness of moving to their own pod.

should emphasize that you should be running your own pod, or at least using one hosted by people you know in real life.

Hmm, should is a strong word here. I've been using Diaspora for more than two years, and I still don't have the know-how to enable me to set up and run a pod, or even to know what it is I need in order to do so.

What we need to do in tandem with this is to focus energies on making it a lot easier for people to host pods, and encourage more and more people to do so, so that the numbers of pods increase. Only then will it make sense to move people off joindiaspora.com, otherwise they'll just move to diasp.org, geraspora or one of the other mega-pods.

I'm going to make some proposals about this in the next few days, once the anniversary is out of the way, as it would be really good to discuss how we can achieve this.

Well, what is the usefulness of moving to your own pod? Except for better privacy, I don't see any. It costs money and time and does not give the average user much in return. Also, features like tag following are useless on a private pod.

That's why part of the answer is to solve the federation problems so that being on a single-user pod gives the same experience in terms of what posts you see as being on one of the mega-pods.

@tomscott I see where you're coming from with "Add Forks, Not Features", but part of my concern there is that forking away from upstream will eventually cause incompatibilities between the upstream development and the fork itself. Of course, we don't want Diaspora to become something bloated, with a billion Facebook-like features, but I don't think encouraging numerous feature forks is optimal.

I'd really hate to see us get into a Diaspora-Pistos situation all over again, where the fork diverged so far from upstream that we really couldn't pull any of his changes back in without heavily refactoring them. We've lost multiple community devs because of this problem before.

@seantilleycommunit i think that was more about a disconnect between Pistos and the rest of the community. and it was during a time when we (that is, the Diaspora developer community) weren't as cohesive...it was easier to just go down your own path and not know what's going on with the rest of the community. I'm not sure that situation with Pistos invalidates the "forks not features" idea, but I understand your concern based on Diaspora's past history.

In my opinion, it's YOUR responsibility as a developer to maintain your own fork and keep merging in changes from upstream.

Why should it matter what "features" each pod has? Personally, I think the power of federation comes from the fact that my pod doesn't have to run the same code as yours, but it does have to agree upon a communication mechanism and API structure, therefore we can still communicate. But if I want to rebuild the Diaspora UI in Ember.js on my fork, I feel like I should be able to do that. Additionally, we don't release that often, therefore it shouldn't be hard to keep up to date with 'master' on Git.

I think you are both right :) And luckily the work on separating the D* federation has already begun.

It's good that registrations at jd.com and diasp.org have closed, a good move to try to balance the network a bit. However, there needs to be a clearer message on the jd.com home page.

Yesterday, after the various announcements and media articles, there was a spike in registrations, with almost 100 in the two hours before jd.com closed to registrations, 95% of them being to jd.com itself. (This is going on new accounts sharing with the DHQ account.)

In the 18 hours since jd.com closed its doors, however, there have been fewer than half that number, at 47 new registrations.

This suggests that people are still arriving at jd.com and not knowing what to do, and giving up.

We need a really simply and clear message, nice and prominently, on the jd.com home page, linking to the diasporafoundation.org site where all the information on how to choose a pod and sign up is located - not to podupti.me. Something like:

Want to join diaspora*? Click here to find out how!

In big letters.

@maxwellsalzberg would you be happy to make this change? It would be a big help, I think. Thanks in anticipation.

btw on joindiaspora.com’s front page you can read this: “Diaspora is Decentralized! But don’t worry!”, shouldn’t it be “But don’t worry! Diaspora is Decentralized!”? Also, "set up your own pod" is an empty link. @maxwellsalzberg?

I think right now, it is much too complicated to find out how to join. Something like pump.ios random pod link would be great, I think. Just a link that goes to the sign-up page of a random pod.

I don't want something random. At least something geolocated. A user should register in his own country if he didn't know where to go.

Yes, as one of the key points of Diaspora is that 'you can choose where your data are stored', it would be ironic if we forced people to accept a random pod.

Well, this would not be forcing them. The link could be in addition to the current content. It could also be really explicit about what it does, for example "Register at a pod near you!", which would lead you to random pod near your geolocated position.

We should also really start to work on account migration between pods, as this would make the initial choice of pods mostly meaningless.

I really like the random link - in addition to just being able to choose a pod :)

@jasonrobinson perhaps two links:

Full Directory | I'm Feeling Lucky

=D

Partially related, I have a discussion going on here about non-Amazon non-US privacy-respecting places to host. It may be a good idea to try reaching out to some of these places to see how hosting a pod on there would be. If it's an affordable platform known for strong user policies, we could probably recommend their services to newcomers looking to self-host.

I think it's good to add links to other community lists of pods, not just the pod uptime which is not the most comprehensive list.

Examples:

https://diasp.eu/stats.html
https://diapod.net/active

It will give users better idea that Diaspora is not limited to one list, one server and etc.

OK, I'll try this again. Registrations to the network have been drastically reduced since jd.com closed its doors. At the moment registrations are running at between 10-20% of what they were before jd.com closed its doors - 22 registrations across the network overnight, whereas the figure was usually between 100 and 200 before jd.com closed its doors. It seems to me that people must be following a bad link to jd.com (or using Google), and then not having a clue what to do when they can't sign up at jd.com.

The message is really unclear, and therefore unhelpful.

We need a clear direction to the project site, where there's plenty of clear information on how to choose a pod and to sign up. I suggest, prominently and in big letters:

Want to join diaspora*? Click here to find out how!

Instead of the long text with a link to podupti.me.

Otherwise we're creating the buzz that diaspora is dying because people can't get into it, just when we were getting some good buzz about it thriving under community leadership.

@maxwellsalzberg @seantilleycommunit I'm mentioning you again, and please can we at least have some response this time rather than the silence I've been getting since I first raised this on Wednesday? This situation needs to be sorted out, and it would be so easy for you to sort it out. It just needs a small change to the jd.com landing page, as suggested above.

Ill change it with the next deploy.

Also, you can just make a pull request the joindiaspora branch, it's all open source

thanks @maxwellsalzberg and you're right, we should look at the jd code too ;)

Btw @maxwellsalzberg how is joindiaspora funded these days? Really relating to moving it to the project - how is the project going to pay for it? Do you have any sponsors for the pod and will those sponsors?

Note, people are still registering on joindiaspora even now. How is it possible when registrations are closed? Invites may be?

Yup, invites.

@goob Joindiaspora invites still work?

@diego yep

@jasonrobinson If I understood you well, I don't think making joindiaspora a part of the foundation is a good thing. Diaspora is meant to be decentralized, and having a central point is not helping to achieve that.

joindiaspora.com needs to be closed ASAP. As soon as migration is released there must be a deadline for members of joindiaspora.com to find another pod. I'm not sure what the progress is on pod migration but in my humble opinion it should be the only feature being worked on at this point. Judging by the situation, the need for migration has become an emergency.

joindiaspora was never meant to last for an extended period of time. Just until the migration feature was implemented. Diaspora is in the best state that it has ever been so I feel like sacrificing other new features for migration is the most logical thing at this point.

In other words: It's time to focus fire the effort. :)

@macieklozinski AFAIK joindiaspora will be moved to the project - want it or not. It comes as part of Diaspora Inc moving assets to the project.

@justinmoore why? Joindiaspora is just a pod among others. At least it will be the more time goes by. It would be insane to close it just to force users to change - and thus lose probably half of them as dissatisfied users.

Also I don't see why the existance of joindiaspora as a project asset will limit decentralization. We should just make sure to control the size of the pod - which has already been started.

@jasonrobinson I think if joindiaspora is an official foundation pod, It has somewhat favored position comparing to other pods, the way that it was prior to registration closing. In my opinion returning to that situation would not be good.

@macieklozinski there is no official Diaspora pod. The fact that joindiaspora will or has been transferred to be a project governed asset will not change this.

Note that it has been here that the community requested closing of registrations. It was not something that the previous joindiaspora.com maintainers wanted to do.

The community here wants joindiaspora.com not to be a central pod. So I doubt there will be any favouring - probably the opposite ;)

@maxwellsalzberg in relation to this latest discussion on Github, would you mind updating status on the future of joindiaspora.com?

At some point you were saying it would be maintained by the community. Do you plan to maintain it in the future or do you want it moved to the community? How are the costs handled if that happens?

So, after reading the further posts I have some objections.

1. @cyclux mentioned an interactive map, which @shmerl first put in here. But instead of using cytoscape to reach the goal I'd go for jQVMap :-) I'm volunteering for writing a PoC, if someone can point me to a machine-readable source of the information needed.
2. As it goes for geolocation, be aware that it can only be a nice-to-have, since the user have to give their consent to it.
3. As @cyclux is also offering to write a template letter I want to highlight Google Alerts, which could be used to keep up-to-date concerning joindiaspora.com mentions in the press. (I know … Google … but I don't know another tool with this functionality).
4. As far as I know, the branch mentioned by @tomscott simply does not exist. I only know about 'develop' and not 'master' …

I really disagree with any location data.
Better is there language informaion.
What is location data there for? I can have russian pod in USA. For some reason. Maybe I can have nort korea pod in south korea. I really don't understand location data.
podupti.me is fail also. There is server location, but me question is, for who is this information?
I as server admin don't want have location public, but preffered language or community yes. Me pod is Slovakia and Ukraine.
Maybe there are some possibilities to detect server location, but in case anonymisation there is service as tor to hide server location.

Me answer to any location is: fail

@maxsamael , poduptime is supposed to help users to choose a pod. the location helps since usually a closer server gives better performance for the users.

@itai I will never public there pod server when is there location. Preffered place or language yes, but location never. Even when are based on IP.
Ok, I run server behind the TOR and this will me produce some waste there, no thanks...
I think the diaspora is aimed to secure data, then using TOR is good option. But anyway, I can put the pod to all the world.
Next thing, location aren't no only one factor to the performace. There can be used good CDN service and this value isn't used in this statistic. I can't find if the pod has CDN service or other support service as replicated servers etc...

We are going out of topic here guys. This has nothing to do with joindiaspora...

With a name like JoinDiaspora shouldn't you have something like this as your frontpage?
https://social.mbuto.me/podmap.html

@frodelindeijer, the content of the front page is the responsibility of the person who maintains that pod. It's not a diaspora* project resource - like all pods, it is independent.

diaspora*'s project site is at https://diasporafoundation.org/

I just wanted to say: hurrah, all the performance problems with joindiaspora are now solved, with huge thanks to @zauberstuhl for fixing it all, and to Maxwell for transferring ownership.

One problem to me is that there is no central login/register site. Googling for diaspora will lead you to joindiaspora. So it appears to be THE official diaspora site.

What would be better is to use a central register/login site (maybe on diasporafoundation.com?).
When wanting to register you are proposed that you could
1. Setup your own pod if you like
2. Ask a knowledgable friend to set one up
3. Choose from a list

The list should include information about privacy rating, ...

Also, when logging in it would be advantageous to have a central site to do so. When signing in as ***@joindiaspora.org it would simply redirect the request to the proper pod.
Advantages:
- When pod is down user does not sit in front of a non-working diaspora. He can be informed that "Your pod is currently down. If this happens to often consider migrating your account."
- A user does not need to remember weird pod site names.
- It boosts the central diaspora site to be the hit for google results

I personally am on joindiaspora. I'd have no way of finding out that there are privacy issues. Maybe it would be good to have a box on the pod page that is connected to the central information list. So when a privacy, fraud or anything happens, the user can be informed directly on the pod site, potentially proposing her/him to migrate to another more secure pod.

Edit: Privacy issues could also be handed to the user on the main diaspora homepage, right when she/he is logging in.

@timoses there is no privacy issues anymore, the pod is now hosted in Germany without any American service being used.

Your idea is not a good one because it will bring a single point of failure which is exactly what we're trying to avoid building a decentralize network

Hi Ellen, thanks for your comment. If you look at the date of Roger's comment that you quoted, you'll see that it was made before Let's Encrypt existed. Many pods do now indeed use Let's Encrypt, and it's even suggested in Diaspora's FAQ for pod maintainers.

I think it would be already a good step forward if in the documentation for podmin they would give a rough estimate of how many users a server with a specific configuration could host. For example I'm the podmin of diasporing.ch and I have a dual core with 6gb of ram, what could be my user limit?
Same for sidekiq workers absolutely no information about how many of them you need for a particular installation. The diaspora.yml file only tells you to increase it with a moderate sized pod.