@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.
@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.
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?
@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.
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.
@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 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.
@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 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
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.
@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.
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.
@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.
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. 😜
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!
@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)
@bjoern I think no one doubts qualities of XMPP as a base for closed solutions, but unfortunately it utterly failed as a federated service.
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.
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.
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.
@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. https://xmpp.org/extensions/xep-0167.html#appendix-revs
@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.
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!