Show HN: Kaiwa, a Modern Open-Source XMPP Web Client(getkaiwa.com)
getkaiwa.com
Show HN: Kaiwa, a Modern Open-Source XMPP Web Client
http://getkaiwa.com
141 comments
I bet the entirety of the GNU projects (Free reimplementations of closed-source products) must blow your mind.
They are like the Rocket-Internet.com of Rocket-Internet.com...It's getting almost too meta for me to handle.
More seriously, what's the problem here? Maybe they actually take security seriously (compared to Evernote), and maybe syncing on Polynote isn't fundamentally broken! (a boy can dream)
More seriously, what's the problem here? Maybe they actually take security seriously (compared to Evernote), and maybe syncing on Polynote isn't fundamentally broken! (a boy can dream)
They built a kanban board and a collaborative notes application. There is nothing wrong about that.
Quite the contrary: Project and knowledge management or so important that you should not have just one (and additionally closed-source) application for that.
It's good to have competitors who focus on different workflows (Evernote was not built to be collaborative, Trello does not offer other display modes such as cards and a basic calendar).
I would not complain if they created another CRM as simple as Highrise or an open source helpdesk that could replace Zendesk (I really like helpful.io for this, btw).
Quite the contrary: Project and knowledge management or so important that you should not have just one (and additionally closed-source) application for that.
It's good to have competitors who focus on different workflows (Evernote was not built to be collaborative, Trello does not offer other display modes such as cards and a basic calendar).
I would not complain if they created another CRM as simple as Highrise or an open source helpdesk that could replace Zendesk (I really like helpful.io for this, btw).
[deleted]
A slight tangent, are there public XMPP servers?
Are there open source projects that use XMPP for their public channels?
I'm a little dismayed by how many Slack accounts I'm acquiring.
Are there open source projects that use XMPP for their public channels?
I'm a little dismayed by how many Slack accounts I'm acquiring.
DuckDuckGo offers a great public XMPP service - https://duck.co/blog/xmpp-services-at-duckduckgo
There are loads of them. https://xmpp.net/directory.php has a (not-so-up-to-date) list.
Livejournal.com
Fastmail.fm
I'm curious how E2E encryption (OTR e.g.) could be implemented with a client like this (preferably without having the keys leaked all over the place), it's the only interesting feature I miss from a quick glance.
Unfortunately, this won't improve your security. The client code comes from the server, so you need to trust it anyway. While it is possible to implement OTR or PGP in the client, the server admin could poison the implementation code and leak your private keys.
> The client code comes from the server, so you need to trust it anyway.
Sure, but we have TLS for that. E2E is still needed to cover everything else (e.g., I trust the server now, but I don't want to have plain-text logs on it in case the feds seize it).
Sure, but we have TLS for that. E2E is still needed to cover everything else (e.g., I trust the server now, but I don't want to have plain-text logs on it in case the feds seize it).
TLS doesn't help you there. A server could just as easily serve you a maliciously modified OTR plugin.
OTR also breaks Message Archive Management (MAM) and Carbons - the two features making multi-client operation any useful, and highlighted in the article. And with MAM, there actually are plain-text logs of your conversations on the server.
The call is still open on end-to-end encryption over XMPP when multiple devices (or more than two parties) are involved.
The call is still open on end-to-end encryption over XMPP when multiple devices (or more than two parties) are involved.
The issues you list (message archive being plain text, key management when multiple recipients are involved, maybe even transparently) don't seem to be XMPP specific.
Is there any chat system out there with end-to-end crypto and reasonable support for multiple devices?
Is there any chat system out there with end-to-end crypto and reasonable support for multiple devices?
As funny as it sounds: iMessage. The only crypto-related problem with iMessage's encryption is that Apple controls the key servers. -- http://techcrunch.com/2014/02/27/apple-explains-exactly-how-...
Besides, it is not available for non-Apple devices.
TextSecure/Signal has a robust crypto system, and they are working on multi-device support.
Besides, it is not available for non-Apple devices.
TextSecure/Signal has a robust crypto system, and they are working on multi-device support.
They aren't XMPP specific, but OTR as implemented in e.g. Pidgin goes above and beyond in making them bad – archiving is either plain text or disabled, keys cannot be changed at all (so not even manually syncing them is possible), and session handover doesn't work (there's a session management implemented, but it doesn't do anything except silently eating messages).
> The client code comes from the server
How about hosting E2E js lib somewhere like on Github and include them there?
Or you can always map to local js files.
How about hosting E2E js lib somewhere like on Github and include them there?
Or you can always map to local js files.
If you have a modern browser you can do crypto in the browser.
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
As a freelancer today i need to use a plethora of different messaging apps like skype, hangouts, slack, hipchat, irc + a couple of others for private messaging like iMessage, WhatsApp, Facebook, Telegram. It is really becoming somewhat annoying.
The deploy to DO ain't working.
Looks just like Slack.
Some people would say that's a good thing. I think the more important point is that it's 100% under the control of the organization or users who deploy it.
The UI feels like a 1 to 1 copy of the Slack client, or is Slacks UI so common now copying it is just using the Chat-UI standard?
What's so original about the Slack ui? It's channels on the left and conversation on the right. A lot of irc clients look this way.
Slack borrowed a lot from earlier UIs, too. It's not like Slack is hugely innovative in this department, anyway. You pay for the service, not the UI.
For me the UI and its interactions is part of the service. UIs are really dominant when it comes to experience of a service.
Great Work! This is exactly what I was looking for to deploy on my work, We are still stick on IBM chat, and this will blow people out of Water.
If you disabled or drastically resized the avatars and put the usernames not in a separate line, the window could hold a lot more content for single-line conversations like that.
If they wanted to borrow from Slack (as they have for so much of the UI), they could make that toggleable. Slack lets you disable avatars entirely and/or switch to a single-line view.
Maybe open a pull request? ;)
In my opinion, it doesn't matter if it looks like Slack. What matters is that I can deploy it on an existing infrastructure and still have control over the service instead of handing over control to a third-party.
> What matters is that I can deploy it on an existing infrastructure and still have control over the service instead of handing over control to a third-party
And its nice to be able to choose which apps you want to use on all the different platforms; and choose differently than everyone else. The app that works for me isn't necessarily the app that works for others, but I still want to be able to talk to them using the app I want.
And its nice to be able to choose which apps you want to use on all the different platforms; and choose differently than everyone else. The app that works for me isn't necessarily the app that works for others, but I still want to be able to talk to them using the app I want.
I for one welcome slack competitors, self-hostable, open sources ones especially.
Maybe you'll be interested in Talqee [1] which offers a self-hosted version. It's coming really soon :)
[1] https://talqee.com
[1] https://talqee.com
We're supposed to pretend a paid app will be competitive in this space.
hillarious way to advertise, chum.
hillarious way to advertise, chum.
There's Candy: http://candy-chat.github.io/candy/
Check out http://sdelements.github.io/lets-chat/
Let's chat is really neat, I've played with it a lot but I have to say that the combination of not supporting OTR & The fact that it relies on MongoDB put me off using it in production to replace our existing chat server.
Let's keep in mind that Slack looks like IRC.
HipChat does this: https://www.hipchat.com/server
In my opinion, it does matter. Slack is pretty and familiar, so an app looking alike is a good thing.
"Familiar", eh? To me it's still "that weird new hipchat competitor people keep talking about", but it's still something operating at a couple of degrees' remove: I've never used it or met anyone who uses it or heard of any reason to use it, and the one time I went to the website it wasn't clear that there was any way for random people to sign up for it. I'm curious why you see it as the established standard - isn't it basically brand new?
Slack built up $11m in annual revenue in a really short time, and is adding $1m in contracts every 11 days. At what's about $7/person/month, that's a lot more than no one.
http://www.businessinsider.com/slack-growth-after-one-year-2...
http://www.businessinsider.com/slack-growth-after-one-year-2...
Maybe I'm just old and cranky, but to me both Slack and Hipchat are IRC knockoffs.
Is there a good mobile client to use with a xmpp serveR?
Besides of the ones referenced in the article, there is also ChatSecure [0] for Android and iOS (with a strong focus on security) and Xabber [1] and yaxim [2] for Android (I am the maintainer of yaxim).
[0] https://chatsecure.org/
[1] http://www.xabber.org/
[2] https://yaxim.org/
[0] https://chatsecure.org/
[1] http://www.xabber.org/
[2] https://yaxim.org/
I've been using Monal <http://monal.im/> on iOS - decent UX, supports groupchat, doesn't put a "proxy" between you and your server, etc.
Coming from the patron saint of XMPP, that some recommendation :)
Thanks for the suggestions. Do they also provide the group chat support? As, I believe, the 'normal' XMPP protocol doesn't support groups.
Not sure about ChatSecure, but xabber provides MUC (group chat) support out of the box, and for yaxim there is a beta APK you can get here: https://yaxim.org/muc
The beta's limitations are:
* rather broken invitation handling user interface
* cumbersome MUC joining user interface
* impossible to downgrade to non-beta builds
The beta's limitations are:
* rather broken invitation handling user interface
* cumbersome MUC joining user interface
* impossible to downgrade to non-beta builds
I've been using Conversations (Android) with Kaiwa for the past few weeks and it has worked very well so far: https://play.google.com/store/apps/details?id=eu.siacs.conve...
Excellent work.
Is there a reason why you chose Prosody over MongooseIM or ejabberd?
Is there a reason why you chose Prosody over MongooseIM or ejabberd?
Thank you.
We chose Prosody because it supports the XEP we needed and it was originally used by Otalk from which we forked.
Could you talk about why you forked Otalk? All I could find was the diff[1], and it seems like Otalk is still active.
1: https://github.com/otalk/otalk-im-client/compare/master...di...
1: https://github.com/otalk/otalk-im-client/compare/master...di...
Relatedly, why are you recommending only Pidgin, and not Gajim? Gajim covers a lot more XEPs than Pidgin (e.g. editing sent message).
We have updated the page to recommend Gajim instead. It is a better choice indeed.
Also Conversations doesnt allow for customer server IP address so it's unusable for me. Yaxim does which is why I will have to stay with it. Custom IP server addresses are important if you have DNS/NAT complications within your internal network compared to outside.
Can you use SRV records for this? Or is that unsupported too?
Also, I don't believe that Monal is open source. You might also want to add https://chatsecure.org/.
In my experience, prosody has an easier to configure (and thus harder to fuck up) LDAP integration, and while ejabberd's core is solid, the modules vary wildly in quality (I never managed to get mod_shared_roster_ldap to work, e.g.).
Can I chat with Google Talk users from this?
You will first need an XMPP account but then you can add GTalk users to your roster and chat with them.
GTalk has broken federation for Hangouts users, and they failed to enable s2s encryption, which is mandatory since February: https://github.com/stpeter/manifesto/blob/master/manifesto.t...
Can you explain, or point me to an explanation of, _in detail_, exactly what GTalk broke in terms of federation?
I find that in practice I can _sometimes_ communicate with _some_ users from _some_ clients, but it seems like it's flaky and there's not a clear pattern to it. Do you have any deeper insight?
I find that in practice I can _sometimes_ communicate with _some_ users from _some_ clients, but it seems like it's flaky and there's not a clear pattern to it. Do you have any deeper insight?
Most of the XMPP network switched last year to REQUIRING encryption for one server to talk to another server. Google doesn't support encryption at all for server-to-server links, and thus servers like jabber.org (of which I'm the admin) can't talk to Google anymore. See more at https://github.com/stpeter/manifesto/blob/master/manifesto.t...
Actually we (most of the XMPP network) switched over to mandatory encryption last May and IMHO it's been pretty successful so far. Google is welcome to join the party anytime! :-)
Sounds a lot like Google's behavior on GTalk amounts to 'embrace, extend, extinguish'... except that they failed.
On Gmail, you'll need to "revert to old chat" if you've enabled the "new Hangouts".
It's not hard to get a UI like Slack's. The actual chat window is just like what IM clients have used for decades. One side has the contact and chat room (channel) list combined instead of in a separate window. Like in IRC instead of XMPP and other chat systems. Put the settings and away management in a header or footer and you've got slack.
It's not like it's revolutionary. They put two and two together in the only reasonable manner for a single-page application.
It's not like it's revolutionary. They put two and two together in the only reasonable manner for a single-page application.
Good work .
I'm planning on setting this up for myself later today but a few questions before I do that:
- Will this stay connected to my account and the history will be there if I close the tab / browser / computer in the meantime?
- Is it possible to replace certain strings with images? This is not at all an important feature but just something I got used over the years. (Example: :string: replaced with image.png and displayed inline. That's possible with Adium but I'd really like to replace Adium)
Thanks!
- Will this stay connected to my account and the history will be there if I close the tab / browser / computer in the meantime?
- Is it possible to replace certain strings with images? This is not at all an important feature but just something I got used over the years. (Example: :string: replaced with image.png and displayed inline. That's possible with Adium but I'd really like to replace Adium)
Thanks!
On the homepage they mention they use Message Carbons, so your history should be retained, yes:
Using Message Carbons (XEP-0280) all of your active conversations will be synced to your Kaiwa client.
I don't think that applies. Unless I misunderstood the GP.
I understood the question as "will I be able to receive messages while the tab isn't open" (offline messages) and "will I be able to read my history on a different device later on" (MAM). Carbons serve a different purpose and sync connected clients (i.e. you chat on your desktop, but your phone receives the same messages as a carbon copy to stay in sync).
I understood the question as "will I be able to receive messages while the tab isn't open" (offline messages) and "will I be able to read my history on a different device later on" (MAM). Carbons serve a different purpose and sync connected clients (i.e. you chat on your desktop, but your phone receives the same messages as a carbon copy to stay in sync).
I think this is great. If there were more people pushing clients like this, not only will it push the guys who already make money off of it, but we can do a better job coming up with new communication ideas as a whole.
I'm ONLY using Hangouts because they don't allow group messaging in any other client. I'd like to see that change!
I'm ONLY using Hangouts because they don't allow group messaging in any other client. I'd like to see that change!
The very first sentence irks me:
"[…] for the only standardized chat protocol [XMPP]"
Haven't they heard about IRC (RFCs 1459, 2810–2813)?
Haven't they heard about IRC (RFCs 1459, 2810–2813)?
There's also http://matrix.org ; though it's not going down the RFC route (at the moment at least).
</blatant self-promotion>
There seems to be this general assumption at the moment that a) XMPP is the only open chat protocol about and b) its dead, so everyone decides that the only logical course of action is to write and use custom proprietary protocol. This, of course, massively sucks from a UX perspective where I end up having 100s of identities and apps and logins that I use (semi-)regularly to not just chat with people, but also comment on articles, discuss things on mailing lists etc.
</blatant self-promotion>
There seems to be this general assumption at the moment that a) XMPP is the only open chat protocol about and b) its dead, so everyone decides that the only logical course of action is to write and use custom proprietary protocol. This, of course, massively sucks from a UX perspective where I end up having 100s of identities and apps and logins that I use (semi-)regularly to not just chat with people, but also comment on articles, discuss things on mailing lists etc.
(Long time lurker, only a reader till now)
I've been looking for something like matrix for quite some time now (albeit probably in the wrong direction) and it seems like a really cool project. I've been wanting to build a chat application on top of a chat protocol like that for ages! Its a big boost to finally get started. Thanks!
Edit: whoops, I had commented once before, it was just so long ago that I forgot about it!
Edit: whoops, I had commented once before, it was just so long ago that I forgot about it!
Maybe this only matters to me, but my biggest gripe with IRC as a protocol is the lack of embedded newline ability. Take away newlines and now you've prevented atomic code snippets and killed newline sensitive markup suck as Markdown.
I deeply appreciate the history and communities available on IRC, but as a protocol, good riddance to it.
I deeply appreciate the history and communities available on IRC, but as a protocol, good riddance to it.
https://tools.ietf.org/html/draft-movva-msn-messenger-protoc...
MSN Messenger's protocol was submitted to the ECMA in 1999, but MS made changes to their implementation almost immediately that were never documented.
MSN Messenger's protocol was submitted to the ECMA in 1999, but MS made changes to their implementation almost immediately that were never documented.
Also, SIP/ SIMPLE.
Use it with an Ejabberd server? It has IRC support as well.
https://www.ejabberd.im/mod_irc
https://www.ejabberd.im/mod_irc
OK, my bad: The oldest RFC is just "experimental" while the newer ones are "informational", and explicitly stating "It does not specify an Internet standard of any kind."
No wonder its not standardised, considering that almost any server out there uses a different, partly incompatible set of extensions (for server-to-server communication, at least), depending on which servers it was forked from (very few are not in some way derived from the original ircd[0]).
[0] http://en.wikipedia.org/wiki/IRCd#/media/File:IRCd_software_...
[0] http://en.wikipedia.org/wiki/IRCd#/media/File:IRCd_software_...
I noticed that too, plus the fact that the "Rooms" are preceded by # signs in the list. There's probably some IRC influence.
Slack uses that # convention as well (also probably inspired by IRC).
That and the use of hashtags to group things together on Twitter, etc.
I guess it's just a "thing" now.
That and the use of hashtags to group things together on Twitter, etc.
I guess it's just a "thing" now.
The click to deploy on Digital Ocean is pretty cool.
Great to see open source apps promoting open protocols - made me sad to see FB and Google moving away from it
Is there any chance we will see webhooks in a future release? (ie. slack integration)
screen + ssh + irssi (+ bitlbee, if you need xmpp) > any web based solution. Why? Because I can see it on my phone and on my laptop, and it's as lightweight and simple as a `ssh -t irssi.myDomain.foo screen -DD -R` and I'm all caught up.
This is, ofc, my $0.02. Stuck in the old way of doing things, I guess.
Still pretty cool, particularly the deploy on DO.
This is, ofc, my $0.02. Stuck in the old way of doing things, I guess.
Still pretty cool, particularly the deploy on DO.
How do you get notifications, particularly on your phone? With e.g. AIM I have an equally lightweight experience on the laptop (just browse to the URL), a functional app on my phone, and, crucially, push notifications that alert on my phone.
I bet you could hook irssi to sendmail on a regexp match of your name if you wanted, get SMS alerts.
Quick google found https://github.com/paddykontschak/irssi-notifier/blob/master...
I don't bother with it though. If I'm away from a computer, I don't need to see it.
Quick google found https://github.com/paddykontschak/irssi-notifier/blob/master...
I don't bother with it though. If I'm away from a computer, I don't need to see it.
Except for being almost unusable on smartphones (or barely usable on devices with qwerty keyboards), and bitlbee's arcane syntax for joining MUC chatrooms, this is the exact setup I am using.
I don't have any trouble at all using Colloquy on iOS and connecting back to my bouncer. It's about as seamless as you could expect all things considered.
Does your bouncer let you view the full scrollback from multiple clients, without having to keep them constantly connected (and preferably without lagging out one's mobile client when it connects and the bouncer deluges it with old messages)?
There are a few different solutions for this out there, especially clients that run some custom protocol between the GUI and the bouncer, like Quassel and Smuxi - but I've tried both, and each both (a) has poor mobile support and (b) once you get used to it, turns out to just suck in general. (These opinions are a few years out of date, though.)
Thankfully I don't actually care much about mobile support: I don't use IRC for time-sensitive discussions, and for recreational purposes, trying to participate in a real-time conversation where everyone can type several times faster than you is, IMO, a pain; I'm faster at typing on iOS than I used to be, but it's still just not comparable to a real keyboard. Better to save the chatting for when I have one. But I find ssh+screen an unacceptable solution: partly because of issues with notifications (i.e. out of the box, there are none) and copy+paste, though both can be fixed in theory, but mainly because of the latency. When the letters I type don't appear for 100ms or more, it really trips me up and I make a lot more typos. I could find a server with less latency at home, but that wouldn't help when traveling, especially on an unreliable connection - even though there is no fundamental reason chat should be latency sensitive in the slightest. Tried mosh (ssh + prediction) as a compromise for a while, and it works better, but it has some issues and doesn't fully hide the latency.
These days I'm using Glowing Bear, the web-based remote for weechat (that uses yet another custom protocol). Latency's gone, and like other web-based clients it has the neat feature of embedding YouTube videos and images, so I'm finally pretty satisfied with my IRC setup. (And I can be paranoid about security and run it on localhost rather than using their website directly.) But there are disadvantages: Glowing Bear is somewhat feature poor, it (again like other web-based clients) is relatively slow to render, and there is no native iOS weechat remote. (Guess I could still use weechat as a regular bouncer, or perhaps try Glowing Bear from mobile Safari...)
There are a few different solutions for this out there, especially clients that run some custom protocol between the GUI and the bouncer, like Quassel and Smuxi - but I've tried both, and each both (a) has poor mobile support and (b) once you get used to it, turns out to just suck in general. (These opinions are a few years out of date, though.)
Thankfully I don't actually care much about mobile support: I don't use IRC for time-sensitive discussions, and for recreational purposes, trying to participate in a real-time conversation where everyone can type several times faster than you is, IMO, a pain; I'm faster at typing on iOS than I used to be, but it's still just not comparable to a real keyboard. Better to save the chatting for when I have one. But I find ssh+screen an unacceptable solution: partly because of issues with notifications (i.e. out of the box, there are none) and copy+paste, though both can be fixed in theory, but mainly because of the latency. When the letters I type don't appear for 100ms or more, it really trips me up and I make a lot more typos. I could find a server with less latency at home, but that wouldn't help when traveling, especially on an unreliable connection - even though there is no fundamental reason chat should be latency sensitive in the slightest. Tried mosh (ssh + prediction) as a compromise for a while, and it works better, but it has some issues and doesn't fully hide the latency.
These days I'm using Glowing Bear, the web-based remote for weechat (that uses yet another custom protocol). Latency's gone, and like other web-based clients it has the neat feature of embedding YouTube videos and images, so I'm finally pretty satisfied with my IRC setup. (And I can be paranoid about security and run it on localhost rather than using their website directly.) But there are disadvantages: Glowing Bear is somewhat feature poor, it (again like other web-based clients) is relatively slow to render, and there is no native iOS weechat remote. (Guess I could still use weechat as a regular bouncer, or perhaps try Glowing Bear from mobile Safari...)
No, nothing I use supports synchronizing scroll buffers beyond ZNC's behavior of dumping the scroll buffer to whichever client is connected (Colloquy on iOS, Textual on OSX). I've not found the dumping behavior to be that terrible, but I don't frequent very popular channels so it's generally not pumping out thousands of lines every time I open the app. For the most part that doesn't inconvenience me, I can respond to any pings or queries as necessary and catch up on conversation. If I need to review anything outside of ZNCs buffers it's a super quick task to just go and read the logs from disk. The main critical feature is not losing private messages and pings when moving between client, which ZNC achieves without fail.
Like for you IRC isn't anything beyond recreational for me, so quirks in the workflow are just fine to work around. If it was my primary method of communication I'd be looking into improving it I suspect.
Like for you IRC isn't anything beyond recreational for me, so quirks in the workflow are just fine to work around. If it was my primary method of communication I'd be looking into improving it I suspect.
Juicessh fixed many of those problems when I used an android phone, ymmv.
And also getting zero uptake from non-tech people.
I've been working with XMPP and a number of XMPP daemons. A couple years later I'm not a fan.
If you have tried Prosody and have any feedback on it, I'm all ears (or drop us an email at developers (at) prosody.im).
I love to receive feedback (of any kind), as it's the only way we know what we're doing right and wrong!
I love to receive feedback (of any kind), as it's the only way we know what we're doing right and wrong!
OK, you have my attention. I having been working with ejabberd and openfire. I'll take a look at prosody. If I have time I'll get back to you.
Me neither. This is the first client that actually piqued my interest… but useful E2E encryption is still an unsolved problem, it seems. (OTR is a usability nightmare.)
> "Combined with Prosody, one of the best XMPP server out there, Kaiwa..."
I think that should say "servers" plural.
I think that should say "servers" plural.
What prevents me from adopting XMPP for my team is the lack of push notifications to my phone. I don't want to have an app constantly maintain a connection and slowly drain my battery.
Push has been formally specified very recently in XEP-0357 (https://xmpp.org/extensions/xep-0357.html), now is the time for implementors to show what they have !
The Conversations app for Android works pretty well. I've used it for a few weeks with a handful of persistent rooms on a Nexus 5 and I haven't noticed any battery issue.
Some years ago I built an Android SDK that did background location and had an XMPP channel open for push notifications. This was before Android had Cloud Messaging available. Battery drain was minimal/negligible.
There has been a deluge of web chats lately (which is a good thing).
Has anyone tried Let's Talk, Shout, Echoplex, and/or Kaiwa in practice and have some experiences to share? Stability, searchability, general functionality?
Has anyone tried Let's Talk, Shout, Echoplex, and/or Kaiwa in practice and have some experiences to share? Stability, searchability, general functionality?
Wow! Nostalgia.
If I remember correctly, "Kaiwa", was the codename for the first Macromedia's Flashcom Server (before Adobe's acquisition).
Flashcom Server at that time made it possible to run 2+ ways multi-threaded communication (audio/video) via the Flash Player (2003-ish).
If I remember correctly, "Kaiwa", was the codename for the first Macromedia's Flashcom Server (before Adobe's acquisition).
Flashcom Server at that time made it possible to run 2+ ways multi-threaded communication (audio/video) via the Flash Player (2003-ish).
No mention of OTR. :-( When your client is a Web app on a trusted server (i.e. OTR key on the server), you could avoid multi-client issues by having only that on XMPP client that you connect to from multiple browsers.
>modern ... XMPP ...
lolnope
lolnope
Now you need to open-source amazing iOS and Android apps too :) Good job, looks great.
very exciting.
need to try it out to see how extensible it is.
need to try it out to see how extensible it is.
Does it use WebSocket?
Yes it does. See install guide: https://github.com/digicoop/kaiwa-server
I am glad projects like these are being worked on. Desktop XMPP programs are terrible. I have had a hard time hosting my own chat service for friends,family and work because the clients never work together for file transfers.
I just wish these were easier ''FOR ME'' to install on FreeBSD.
I just wish these were easier ''FOR ME'' to install on FreeBSD.
There doesn't seem to be much in the way of install instructions for anything, except the digital ocean automated installer, which also sets up a prosody server.
Seems like they have some instructions here[0], which is linked from http://getkaiwa.com/deploy
[0] https://github.com/digicoop/kaiwa-server/blob/master/README....
[0] https://github.com/digicoop/kaiwa-server/blob/master/README....
Ah interesting, I didnt see that, I didn't consult that page much because it seemed to be solely focused on the Digital Ocean stuff
http://digicoop.io/products