Follow

Did you know that uses for their chat? Isn't it ironic that while large parts of the software freedom movement consider XMPP as outdated and refuse to use it, companies building commercially successful proprietary and centralized solutions on top of it... 🤔

@bjoern WhatsApp is also built on XMPP. So it's protocol. That doesn't say much about the software, it's neither good nor bad.

@bjoern we looked at XMPP and IRC for a chat system but decided to start with our own design. I can see the attraction to jumpstart a feature but there are other paths as well.

@Rlaracue what did lead you to this choice? What was missing to xmpp? Do you have any federation process to allow people using we-act to communicate with the rest of the world?

@h30x As I mentioned to @bjoern its more about where we are in development & testing. We have a design we fleshed out with GraphQL, NodeJS, Apollo and Mongo but we wanted to simplify things and do either Flutter or Native atop Firebase. Once we get good user data and a sense for federation/moderation needs we will move to a custom back end and revisit IRC etc.

Flutter/Firebase was st8 forward and less costly as well. Good for controlled beta testing.

@Rlaracue

Interesting. Are you able to discuss what specific requirements you had that led you to reinvent and reimplement the wheel?

(I am guilty of the opposite: trying to shoehorn #XMPP in places where it didn't really fit, out of laziness aka if all you have is a hammer…)

@bjoern

@0 @bjoern It was more roadmap vs giving up in IRC entirely. For the initial release we wanted to test some new takes on group chat and self moderation and do it quickly. IRC was overkill for what we needed at least in an initial product release. I think once we get good user data we will revisit IRC and a Federated server setup.

We may even go with a simple Flutter or Native Client sitting on top of Firebase to test our designs and assumptions.

Happy to DM or do a call any time.

@Rlaracue
#IRC or #XMPP? Also, from your general description this sounds exactly like the ‘X’ in XMPP.

From the protocol side it sounds like a matter of adding a couple of custom stanzas to your stream, which is done literally in minutes. I'd then add the server side logic via a XEP-0114 component.

It's less than a day to prototype, only a couple hours if you're in current practice.

Have you tried this approach? Why didn't it work / wouldn't it have worked?

@bjoern

@0 @bjoern again happy to have a call or DM chat. The developers felt it was more involved given our apps feature set and the ongoing cost of running the system. Irc had complete servers we could leverage and they still recommended starting more simple. Also XMPP lacks the variety of complete free open source chat servers as well. All the decent servers we’re expensive and costly to customize. If we were building a simple chat app XMPP would be fine but it’s more involved.

@Rlaracue

Would I be correct in assuming that those developers were remote subcontractors, possibly from a different continent?

I understand your not wanting to give away your product's “secret sauce” but something is just not making sense here. E.g., why do you need “a variety of free open source chat servers”, as opposed to *one* that ticks the boxes? Not to mention that you can just hire #ProcessOne and get the benefit of their decades of experience doing it right.

@bjoern

@Rlaracue @bjoern

I expect you're also aware of the implications of using #FOSS in proprietary products (if yours is). Those licences are not just for decoration. If you don't do your research properly this is going to get uncovered very quickly during due diligence.

@0 @bjoern We have a 35 year open source veteran on the team to navigate those waters. He is also a long time C developer & IRC guy with experience launching systems to support millions of users. In the end if commercial tools are best we will use them. For an MVP+ its more about getting the product in users hands and confirm design direction & feature prioritization. :)

@0 @bjoern We will have a public Git repo and open source the code of our app. That has always been the plan. We focused on helping as many activists in as many ways as we can. We also think people will come up with new ways to use it and extend it.

@0 @bjoern Local, here in the US on the team. We are talking about an expanded MVP which is more about user feedback testing vs picking the long term stack elements. We also talked to processone early one and for a small bootstrap firm they were too expensive. So if you want to talk about investing we are happy to :) but for where we are at the moment these are the proper moves.

@0 @bjoern We looked at open source IRC servers repos to fast track development and for potential future use. They like XMPP are not off the table but for user testing and development speed standard tools are fine.

@0 @Rlaracue @bjoern Lol it easily takes a day to setup an ejabberd server with the config file you want.

@stevenroose @0 @bjoern At what cost? Without seeing the client design (a lot more than chat & rooms)/use case/personas/budget are you 100% sure it fits? My SysOps guy with 25+ yrs experience downloaded it, several other XMPP server setups, UnRealIRC and several Jabber and IRC clients with the idea of just “tweaking” them. We did not dismiss any of the tech just felt it was overkill for an MVP+. If you want to help us evaluate this option, config & launch it I am all ears. Thx!

@Rlaracue @0 @bjoern I can't speak for that. I think some of the XMPP chat rooms would be better suited for that. Like ejabberd's room or Prosody's room.
Personally it looks like being fluent in the language a server is written in (Erlang or Lua in this case) can help a lot but I know both of them also support external extensions using the XMPP standardized extension protocol. So mostly you should find a library that can help you work with the extension protocol in your favorite language.

@Rlaracue @0 @bjoern And then get some help in some chatroom to configure a server without all the Jabber-specific features but with just enough of the existing extensions/modules to get your use-case going. I know for one that ejabberd's configuration page is quite complete.

@Rlaracue Honestly I can't say if it's a good idea for an MVP(+). I have never done it. But f.e. as a bigger player like WhatsApp or f.e. a Wire that's now implementing federation, I think building on top of XMPP makes sense.

@stevenroose I also spoke to some people working on Apache Vysper. He (long time Java/C guy) said XMPP can be very chatty and have higher cloud costs at least more than a bootstrap could handle if they trip over a hit. He also said some of the room, moderation and other tools are less deep vs IRC. So he also suggested build something simple and test, a lot and then decide on long term server tech.

@stevenroose BTW regardless of traditional or XMPP based comms we are actually in the market for a Go developer now. We want to work with Go and eventually Rust on the back end as we grow. Some of the functions in the client are well beyond chat and will need to be developed outside of the chat server. So if u have some spare cycles or know a strong Go backend person please let me know. Agencies you trust are also welcomed but again budgets are limited re: hr/rate. Thx

@Rlaracue

I'll be blunt. Who's funding this and what is your budget?

@stevenroose

@0 I will be blunt back.. Who are you, your skills and what is your interest?

@Rlaracue

No interest whatsoever. From your postings here it's clear that you are miles out of your depth, that your “team” are similarly unqualified, and that you live in blissful ignorance/denial of that.

Given that, get a one day consultation with process one or one of their competitors and they'll tell you exactly what you need. Better spend a couple grand on that now than pissing it off on some amateur stabbing in the dark.

I find your blather rather boring so I'm going to mute you.

@0 @Rlaracue Wow guys, that escalated quickly.. What happened to being civil or just leaving a conversation if you're no longer feeling like it?

@Rlaracue There is a Go XMPP server implementation called Jackal. And in fact the developer of that might be a good hire for your project. His name is Miguel Ortuno.
github.com/ortuman/

@stevenroose Thanks so much and I appreciate the patience. I am doing the legwork but I am the biz guy. Shocking I know. :)

@stevenroose Never heard back from Miguel. Tried email and LinkedIn. Appreciate the legwork and lead. PS - I am in the market for a CTO as well. Part time and for equity. Social good project. :)

@stevenroose To be clear, which is a challenge fractured statement communications, we will ultimately use one of XMPP or IRC. The goal of the MVP is to get solid user data, validate user design/personas and get funded. If we had the budget we would be more aggressive but between covids impact on the economy and my mother dying suddenly a month ago we had to scale back. I am the bank and now have more personal stuff to support. Thx.

@stevenroose @0 @bjoern We also ran into the Erlang bit (we dont have those skills) but tested a few plugins/libs for accessing XMPP and IRC servers. I think as we work the personas and firm up the final client we will have the data to make a decision between XMPP and IRC. We will need one of them at some point.

@stevenroose

#XEP-0114 is done using a bog standard XMPP client library. Pick your favourite one and off you go.

@bjoern

@stevenroose

A day? For what kind of configuration?

Vanilla single host, single node it's more like twenty minutes, and most of that is spent in generating the SSL certificate and updating your DNS zone. 😜

If we're talking multi-node cluster then it's surely a different story. I have no experience with that sort of setup.

@bjoern

@0 @bjoern But that's because you did this before.
Creating your config or finding an example config is not easy. Matching the config with the correct DNS records is not easy. I'm talking first time doing it.
I recently setup my second XMPP server and I ended up mostly looking at my first one because it was a lot easier than looking up documentation again.

@stevenroose

Actually, I did this a few weeks ago on a new box with the default #ejabberd.yml that came with the distro. I was surprised that it needed next to no tweaking. 😜

Of course, someone who's never seen #XMPP before might take ½ or one day to go through the #RFC, #XEP, etc., but in terms of getting #ejabberd up and running out really *is* a breeze these days. 👍

@bjoern

@0 @stevenroose @bjoern I'm genuinely curious why as an administrator one would need to go through the RFCs and XEPs

@pep

Oh, the conversation was originally in the context of using #XMPP for development so I was in that mindset.

That said, in the past when a new module popped up and I didn't know what it did, besides reading the #ejabberd docs I'd take a look at the corresponding #XEP of there was one. Not necessarily a detailed read, but enough to get a general idea of what the module does and how, to decide if I need it or not.

Besides, a bit of relaxing reading never goes amiss!

@stevenroose @bjoern

@0 @stevenroose @bjoern hell, even a multi-node cluster is easy. With ejabberd you can just spin up two instances with the same config and cookie, and one ejabberdctl command later it's a cluster.

@brian

I've put this down on my to-do list. This is one of those things that I just have to try, for general education and for fun.

Thanks for the tip. 👍

@bjoern @stevenroose

@bjoern Gmail and facebook once used xmpp for their messengers. I remember, back then i used pidgin to connect to facebook-IM. So yeah, your argument is valid in more than one term.

It seems like a lot of solutions use XMPP underneath: Jitsi Meet and even Matrix (that uses Jitsi Meet SDK underneath). ejabberd is also heavily used in MMORPGs to provide chat across millions of users (https://xmpp.org/uses/gaming.html)

This also shows that UX is critically important and XMPP could re-surface if we had more high-quality clients such as https://conversations.im or https://dino.im

@bjoern
A very interesting observation. Perhaps #FOSS enthusiasts are more techie and software-promiscuous, with
#decentralization being the new sexy!
Maybe #proprietary stuff is behind, because they graft their work onto successful #opensource foundations.

@mark xmpp is decentralized. We don't need accounts on the same server to chat. I think xmpp's traditional lack of clients with modern UI friendliness has been a problem for wider adoption. Nowadays #conversations is good, for those with a smartphone. I like #xmpp! @bjoern

:) Thanks for that, @tuttle
I've never used #XMPP (so far as I know).
@bjoern

@bjoern I think no one doubts qualities of XMPP as a base for closed solutions, but unfortunately it utterly failed as a federated service.

@tagomago

No business driver behind it. In today's vision of consumer IT, driven by silicon valley venture capitalists and enthusiastically endorsed by silicon valley capitalist wannabes, it's all about walled gardens.

@sesivany @bjoern

@0 That's not what I understood from @sesivany's assertment. In that sense, every federated service fails, so it's not worth mentioning it. @bjoern

@tagomago
No, he seems to think that it was due to some unspecified technical reason.

> In that sense, every federated service fails

In the sense of not being silicon valley venture capital friendly? Yes, definitely and thankfully.

And what this means is that the thinking in silicon valley needs to be readjusted. Ideally before their too big to fail behemoths fail.

@sesivany @bjoern

@tagomago

It did clearly fail by the measures that @sesivany is using.

He and I disagree on the cause of that failure, not in that it occurred.

It obviously did not fail in the wider sense of becoming the go-to solution for instant messaging and presence.

@bjoern

@tagomago @sesivany @bjoern

I dislike analogies but it's like saying that #Linux “failed” because it's not the dominant desktop OS. By that particular measure yes it did, while still being by far the most widely used OS out there by any of a number of measures.

Chances are high that any given household is running a number of Linux installations yet few people will be aware of them using it.

At a much smaller scale, we see a similar phenomenon with #XMPP.

@sesivany @bjoern Failed?

More like killed.

> While during their growth periods both Google Talk and Facebook Chat adopted XMPP technology. After some time, both removed first some features from it — most notably, of course, the federation ability.

blog.xrds.acm.org/2018/05/wall

@ashwinvis @bjoern Google kept the federation for years and the main reason why it left XMPP was that it was too slow to adopt new features. Their extension for audio/video call Jingle was not accepted into the standard even after 10 years. That's just painfully slow in an area of such rapid development as instant messaging.

@sesivany The first version of Jingle for A/V calls was accepted as an experimental XMPP standard in Dec 2005, about 4 months after the initial release of Google Talk. It's considered a stable draft since 2009. libTelepathy (Empathy, KDE) and Jitsi added support for Jingle in 2007 and 2011 respectively. Google announced to drop XMPP support in 2013, so this is hardly related to XMPP being to slow to accept and adopt the standard. xmpp.org/extensions/xep-0167.h

@sesivany Also I doubt there is rapid development in instant messaging. The huge new features in IM in the last years have been what? Animated stickers and dark mode? That's hardly protocol related, but merely a UI thing.

@sesivany

Jirko, Google killed their #XMPP service for the same commercial reasons that drive every part of their business.

@ashwinvis @bjoern

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!