@rekado when i was playing around with ejabberd, i found the easiest solution would be to simply create an XMPP user for each diaspora user on the pod. and when new users are added/removed, we create/destroy their corresponding jabber user. seems pretty easy since both of them are using a relational DB.
@Tom: I would advise against modifying the DB directly as you’d couple Diaspora too tightly with a particular XMPP server implementation (and maybe even version). XEP 0077 is the standard way to register accounts through XMPP. (My apologies if this is what you meant.)
Hi to all!
This is my first time I use loomio so please have patience!
I don’t know how much voice and votation I have, but I give my personal opinion about this:
I met lot of people that wants to have a chat feature, not a voice call neither video calls. Also I met people that just said “ah! that doesn’t have a chat: it’s boring!” so I cannot convince him to use D*. In other words: people got acustom to chatting instead of talking.
One problem about voice and video is not the implementation, is the Internet “speed” and bandwith. If you’re going to add voice or video, please be sure to make it clearly optional.
If you ask my opinion about this, we should concentrate on chat. Video and calls are too much and has its own consequences(bandwith, services, privacy, etc.). At least, we should have a chat!
About XMPP, it do support creating counts through its protocol(I remember Pidgin asking if I want to create the account or use an already created). Then, the problem is if ejabberd or jabber.org will may be overpopulated and if they can stand so much people registered.
This makes clear why should be a separate service and not hosted in Diaspora servers, maybe some pods cannot stand such load. Diaspora can give an easy and beautiful
web interface, but the rest is up to jabber.org(and we support Jabber!).
I haven’t take a look into WebRTC, but for now I vote in favor of XMPP: is mature enough for give more robustness to D*.
Cheers!
Welcome!@rekado at this point, i think just supporting a single XMPP server would be sufficient for our needs, but regardless if we can use a standard to make sure that our code is “future-proofed” for any other standards-compliant XMPP server that gets invented in the future, that seems like the “right way” to go.
@rekado to answer your question, i think XEP-0077 (http://xmpp.org/extensions/xep-0077.html) is a fine spec to go by when registering accounts on the XMPP server. there is an XMPP lib for Ruby, so we can send messages to the configured server like when a user is registered through the web interface.
Actually, there’s more than one XMPP lib for Ruby. I recommend using blather (rather than XMPP4R), because of its cleaner design thanks to running inside an EM loop.
so, this is the direction I see this discussion going:
D* associates a Jabber ID with a D* user. That could be a user-specified, existing JID - or - D* offers to create a Jabber account on a user-specified server via XMPP protocol (could have a nice auto-complete for a few known servers).
(the password would need to be stored in the DB unhashed, but we could at least encrypt it with the users private key)
The UI offers a ‘chat’ feature, that’s more or less simply a Jabber client in the browser, connected to whichever account is specified in the D* users profile.
The exact implementation details are still to be decided…
@florianstaudacher I just signed up because I wanted to write exactly what you already said 
Just adding this: When user A starts sharing with user B the JID of A could be send to B. When B also starts sharing with A (so both know each others JID) we could add the JIDs to the jabber contactlist
It appears that many existing XMPP users will have to either get new accounts or install BOSH on their server to use such a feature.
@steffenvanbergerem do you mean that user A adds B or just display it?
If adding, D* should ask in which group to add B.
This is useful when we’re talking that D* server forward messages to Jabber servers.
@sethmartin what @florianstaudacher mean is that D* will only associate an XMPP account to the user, and then will only act as a client(maybe using Javascript or other).
If you have an existing account you associate it with your D* user.
I suppose that there’s no need to alter the server functionality, the problem reduces to find a good free jabber client to embed into the webpage. Or, if I forgot something about securities issues, the server just act as a passarel, fowarding messages to the Jabber server.
Am I right? :-S
I found lots of free(as in freedom) Jabber clients and libraries written in JavaScript: JSJaC, Candy. Take a look at the Jappix Mini feature looks interesting…
Hope this helps a bit more…
@christiangimenez all of these require BOSH because that’s the way to write XMPP clients for the browser…
You’re correct, it use BOSH. I learn something new! 
If you were fine with the idea that users had to create a new XMPP account through Diaspora, then you would not need to use BOSH and the JS side of things could be rather simple (= no need for a full XMPP client in JS). Instead of distributing a full client to the users, you could push messages through a websocket in either direction; the websocket server process then takes over the role of an XMPP client.
The benefit here is: no need for BOSH, smaller JS footprint, easier to customise the chat interface, you can use Ruby + blather to interface with the XMPP server in an event loop rather than using the chopped up XMPP-via-HTTP thing that is BOSH.
yeah sure, that way we could achieve much tighter integration with our application, but it would also increase the work required to do this feature.
Also, I’m no expert on Rails but the googling I have done lately indicated that Rails is not particularly good at doing anything else apart from HTTP request-response cycles. Websockets and all the other nice tricks require a separate event loop that’s outside the Rails app, meaning additional ports would be needed to be opened for D*. (Please correct me, if I am wrong.)
So what I’m saying: a standalone chat server in ruby appears to be no problem, but integrating one in D* - even if it’s just to relay XMPP messages to the client browsers - is a completely different story.
Websockets and all the other nice tricks require a separate event loop that’s outside the Rails app, meaning additional ports would be needed to be opened for D*
To support websockets you only need to run a websocket server. This is a simple, separate process (e.g. written in Ruby) that dispatches on messages that come in via websocket. This process can (and should) operate independently from the Rails application. Thanks to library support for websockets, it’s very simple to make this work. The separate process could be spawned during initialisation of the Rails app, so it doesn’t even need to be started separately.
One additional port is needed to be open, but I don’t consider this a problem — it’s certainly much less of a problem than installing and configuring an XMPP server.
Proposal: Find a solution for chat that works on (free) Heroku
Yes: Yes, free should work too.
Abstain: I tend to want it but free is not mandatory.
No: Lets screw our Heroku users.
Given that our biggest pod runs on Heroku and that the discussion all goes into the direction of separate ports/servers/processes lets decide this once and for all to ease the discussion.
Outcome: We don’t need a solution that works with a free Heroku account alone but can mandate an external service. But it needs to able to communicate with pods installed on Heroku.
Votes:
- Yes: 8
- Abstain: 10
- No: 5
- Block: 0
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
BOSH is not the only way, and not a preferable one. Better one is Websockets.
As for Heroku - that will require to come up with XMPP, I’m not sure that Heroku is at all geared towards that. It seems to be targeted only to web applications, not to other type of servers. So pushing XMPP server in Heroku would seem like using a wrong tool for it. While it’s good if that could be possible, but any kind of approach with it would be not straightforward. Much cleaner solution for those who rely on Heroku is simply to find another host where to run their XMPP server.
Just to clarify what agreeing to this proposal means: “The WebSockets protocol is not yet supported on the Cedar stack.” https://devcenter.heroku.com/articles/using-socket-io-with-node-js-on-heroku
It’s also impossible to open arbitrary ports, so running an in process XMPP server is also impossible.
Thirdly I wouldn’t consider requiring a third party XMPP server as “working on Heroku”.