Live data from Hacker News

COI – Chat Over IMAP

coi-dev.org

241–250 of 259 posts

Re: COI – Chat Over IMAP

#242

Earlier quoted context omitted.

https://xkcd.com/1810/ even better. But hey, we are using IMAP and Mail which is already in the picture.

haha, awesome. Love the lonely "Apache request logs" circle. :)

I remember paging a sysadmin once through the failed auth log with sudo.

Re: COI – Chat Over IMAP

#243
post #187

Earlier quoted context omitted.

So I want: - multiuser chat (persistent) - voice-calls (let's have them 1on1) - file-transfer - concurrent clients Which mature clients and servers should I choose from, implementing all this (basic) stuff?

All things you need will be covered by Xabber in second half of 2019, on ios, web, android.

promised for 6 years... and remember this thing is commercial, not OS...: "Nonsense comments from clueless commentors. It's not our problem if you didn't update on feb14. Also, it's our app and we do whatever we want, please uninstall Xabber and use something else. You had no voice or rights here besides those that have been generously given by us. Now they are revoked."

Re: COI – Chat Over IMAP

#244
post #209

Earlier quoted context omitted.

Hey, thanks a lot, those clients look really quite great (and polished). Still, if you look at movim you imho experience the problem of the whole open XMPP-ecosystem. Somehow nobody cares for getting other people to support their features and in the end everything moves closed-source. At this point I think this really is a problem of years of standardizing new features and a lot of projects being sold under the label…

I;d like to see a table / chart showing the top 10 or 20 or so xmpp things - and what features are missing from each, along with notes about the language app 1 2 etc is written in, and an estimate in how long it would take coders to add the amount of missing features that others have.. then we could see an estimated total, like for $xx we could get most of these apps all on the same page of features running... if tha…

https://compliance.conversations.im/ not for clients but slowly getting there for the servers. And this is only for a working text-based chat, AV is really of the table. Basically except for conversations, most of the "clients" should be labeled protocol explorers because most of them have serious usability issues with most of the listed XEP...

The worst thing isn't that the standard isn't defined or something, but that a lot of projects are claiming to support XMPP when they only support some core functionality...

Re: COI – Chat Over IMAP

#245
post #187
post #165

Earlier quoted context omitted.

Except XMPP already has several mature client and server implementations since it was around for longer.

So I want: - multiuser chat (persistent) - voice-calls (let's have them 1on1) - file-transfer - concurrent clients Which mature clients and servers should I choose from, implementing all this (basic) stuff?

https://en.wikipedia.org/wiki/Jingle_(protocol)#Clients_supp...

Re: COI – Chat Over IMAP

#246
post #245
post #187

Earlier quoted context omitted.

So I want: - multiuser chat (persistent) - voice-calls (let's have them 1on1) - file-transfer - concurrent clients Which mature clients and servers should I choose from, implementing all this (basic) stuff?

https://en.wikipedia.org/wiki/Jingle_(protocol)#Clients_supp...

Yeah. Did you actually try calling someone with any 2 of these clients?

Re: COI – Chat Over IMAP

#247
I like the spirit of this idea. I'm glad to see existing technologies being leveraged. However, it still seems quite a dog's breakfast of parts and pieces that don't all seem to be necessary.

I'd like to see this split out into several parts, which could then be used together if necessary.

The basic idea -- how to format and transfer short-form (chat-style) messages using existing email standards -- is brilliant. This seems similar to how AMP describes a limited set of HTML, and would be worth defining carefully.

The management of distributed contacts and group lists seems to be a different problem entirely. Personally, I don't need this: I'm fine with using my existing address/contact lists of trusted friends, along with time-tested tools like mailing lists.

The idea of editing/deleting messages seems superfluous and complicated. I've never knowingly used a chat system that provided this feature, nor have I ever wished I had it.

Maybe I missed something, but I didn't see anything about how SMTP would be used. It seems that by the time a short message is wrapped up into its attachments and headers, then sent to to the appropriate SMTP server (along with login & negotiation), I've probably sent over 20KB. That's a lot of data for one tiny message.

I would love to be able to use COI without a special client at all, just my current email client. However, the spec seems to require certain headers that would generally be difficult to configure in most email clients.

I'm concerned that the spec does not include any discussion of error handling. There are many things that can go wrong, especially with an asynchronous protocol like SMTP/IMAP. How are those problems going to be handled?

Re: COI – Chat Over IMAP

#248

I like the spirit of this idea. I'm glad to see existing technologies being leveraged. However, it still seems quite a dog's breakfast of parts and pieces that don't all seem to be necessary. I'd like to see this split out into several parts, which could then be used together if necessary. The basic idea -- how to format and transfer short-form (chat-style) messages using existing email standards -- is brilliant. Thi…

A couple of answers here https://confluence-public.open-xchange.com/display/CoiW/FAQ

Re: COI – Chat Over IMAP

#249

Earlier quoted context omitted.

If everyone shared your (lack of) optimism, then we'd still be stuck with: * Wonky unwieldy hypertext systems instead of the WWW * The Nomad instead of the iPod * The Blackberry instead of the iPhone * GNU Hurd instead of Linux * Geocities instead of Facebook (-- OK maybe that one's a wash :-) The point is, sometimes it's worth trying again until you can make it work.

Those are some really good examples of the opposite of what you intended to say. > * Wonky unwieldy hypertext systems instead of the WWW Which ones? Gopher wasn't hypertext, but it is still going and still a good idea. A conversion to Gopher would be a huge usability and accessibility upgrade for many current websites. > * The Nomad instead of the iPod iTunes is garbage. iPods sucked until (certain models) had Rockbo…

The products you mention are all good examples of niche products for techies. If that's what you want, by all means keep XMPP and be happy with it.

Re: COI – Chat Over IMAP

#250

Earlier quoted context omitted.

Those are some really good examples of the opposite of what you intended to say. > * Wonky unwieldy hypertext systems instead of the WWW Which ones? Gopher wasn't hypertext, but it is still going and still a good idea. A conversion to Gopher would be a huge usability and accessibility upgrade for many current websites. > * The Nomad instead of the iPod iTunes is garbage. iPods sucked until (certain models) had Rockbo…

The products you mention are all good examples of niche products for techies. If that's what you want, by all means keep XMPP and be happy with it.

> The products you mention are all good examples of niche products for techies.

The blind person that told me about how much better Gopher was than the modern web for blind people was not a techie, and I don't think it is moral to treat disabilities as just a "niche."

Post reply on HN