long-polling/comet! 
I don’t think our issue is S2C. Our problem is S2S.
Jonne Haß: Then clarify please what kind of options for XMPP server are possible on Heroku? From what you said, it sounds like they are non existent. So what is the poll about then?
Although it’s not ideal to trust yet another party with your data, third party BOSH can also be used for the few XMPP users that don’t have BOSH. IMO the ideal solution here would be a simple Heroku compatible Jappix mini type plugin like Friendica uses.
That’s what I want to clarify. I’ve not come over a decent solution that allows using XMPP on Heroku without addtional pain/costs for either the users or the maintainer. From my current knowledge it’s impossible. But then a large percent of our userbase is on Heroku, one can only guess the numbers, but I’d be surprised if it’s below 30%. And we can’t say these 30% are on a well maintained and committed pod currently, sadly. While I didn’t read every word in this discussion I saw a clear tendency to use XMPP, possibly over Websocket or BOSH. Again this is not possible on Heroku.
So we need to decide if we want to further seek for a solution that works on Heroku or allow one that doesn’t work well there. Or we won’t move forward in this discussion. That’s what this poll is about, support chat on Heroku or not.
(That "possibly using XMPP is in the discussions title is probably a bit confusing and should probably be changed. Nonetheless it’s an option and not decided yet.)
If supporting Heroku means not using XMPP for the chat - then I’m voting No. My Yes vote was only for the effort to find how to use XMPP on Heroku.
I’d propose to create a poll for using XMPP as a solid base for chat protocol then. And see what people say.
I agree with what Seth Martin said:
I’m not interested in any other solution than
XMPP because I want to take my chats with me
when leaving the browser. I hardly consider it
screwing Heroku users by requiring they use a third
party XMPP server if they want to chat.
@rekado blather looks interesting…honestly i had no idea anything other than xmpp4r existed as a library. wasn’t too excited about using something that hasn’t been updated in 3 years.
I imagine this whole XMPP feature would look something like the setup for an email server. In which you tell it what server to connect to, and what username/password to use. You can also perhaps enable or disable the “sync accounts” feature which would basically create an account on the XMPP server according to XEP-0077. This would enable users to use their existing XMPP server on Diaspora IM.
I think what most people here really can agree on is that they all want a web-based chat UI inside Diaspora. For some, this may mean a secure XMPP server for sending messages that they control. For others, it might mean just hooking up their jabber.org account and simply using the UI. We should make each option available.
Loomio isn’t taking my vote. Though to me the options are broken. XMPP will be split in no and abstain votes, while non-xmpp gets all the yes votes. I think we should count no/abstain against yes, the options are not well thought out.
Anyway, seriously, are we going to plan the feature set of Diaspora* (free, open source, privacy aware etc) on the whims of one proprietary company? If there is a better option than XMPP then let’s hear it - but this HDD (Heroku Driven Design) talk is just mad.
Of course we should allow pods to run on Heroku as easily as possible but it should not control core functionality design.
No problem in counting the majority as absolute one, i.e. not reached if not > 50% of all votes are yes. In fact that was my original thinking.
I don’t want to fight for Heroku. I want to know whether to support it or not. I see the discussion stuck otherwise.
Free at herokus means a starter database with upto 10k rows? Because of the current federation system and duplicate posts you reach 10k very soon, hence you need to pay for running diaspora on heroku. Who is running diaspora on heroku for free?
I know joindiaspora.com runs on heroku but why not using an external xmpp server on another machine?
We should find a solution for chat, not a solution for heroku!
Even if heroku is not allowing XMPP, our decision is not: XMPP or not XMPP. We could also implement a fully working XMPP-chat with a per pod option to disable XMPP-chat for the pod/it’s users. Users of the pod wouldn’t be able to chat. But that is due to limitations of the crappy Heroku settings. Users of better servers will be able to chat with each other.
We shouldn’t let Heroku dictate us how we are using our network. But on the other side we should create our software in a way that it runs even on low-profile machines. We don’t need to implement an evil XMPP-hack for Heroku, but we need the option to run a non-XMPP-diaspora-account.
Then, I don’t get very well the idea of the Yes/Abstain/No options. What does these means then?
If yes means implement it on Heroku, then I have to disagree or abstain… Heroku is no important mather as long as XMPP works. Unless we agree that this is just a start until we decide another better/free/descentralized alternative.
We have to consider that we shouldn’t limite the people runing pods to use Heroku. I mean, if I want to start up a pod, I can do it in my own work/home without any Heroku’s connections.
I can see that we all agree to use XMPP. Is a semi-descentralized protocol and that is atractive! That is cool! 
@jasonrobinson I don’t think it’s so much about bending to the “whims” of Heroku, so much as it is the reality that many Diaspora pods are already hosted there. Crippling a featureset for users on a specific host is just as bad as bending to the whims of that host in regard to development.
I think going forward, we need to consider alternatives to Heroku, if we really want to encourage podmins to move over to be able to benefit from chat. I have heard that OpenShift has some promise, and @jonnehass did some work a while ago making diaspora work with OpenShift.
Basically, if we want to develop XMPP-powered chat and not worry about Heroku, we should come up with a good alternative to it that can better suit podmin needs in regards to these kinds of features we want to do. Otherwise, we’ll need to find something else that works for everybody, regardless of what host they’re on.
@seantilleycommunit implementing a chat solution that is optional but doesn’t work on Heroku will not cripple the existing user base. They just will not get the new feature.
I really do believe we should not base any design on a single hosting solution. Be it Heroku, Openshift or any other. Let’s find the best solution out there, make sure it works on as many platforms as possible and then decide on that. Be it XMPP or something else.
@diaspeu you’re misunderstanding how that works. the database doesn’t lock, it merely begins deleting old records. perfectly fine for a social network that is more about what’s happening right now than what happened 5 years ago. for example, what i wrote on Facebook 5 years ago is not only meaningless but terribly uninteresting to me today.
As I’ve said before, and I will say again, if we do this I volunteer to either code it or head up the team that’s tasked to make this all work.
@tomscott I got it, but at diasp.eu it takes 6 days to get 10000 posts (approx. 6000 from joindiaspora.com), means my last post, 7 days ago, will be deleted Take a look at https://diasp.eu/stats and see how the federation system fill up my db.