search

hackergrrl / ideas

Ideas shared publicly to get feedback & review from the internet community.
MIT License
2 stars 0 forks source link

universal basic chat protocol #6

Open hackergrrl opened 8 years ago

hackergrrl commented 8 years ago

the problem

we're all tired of buying in to each new chat app's network silo, awkward or low quality proprietary client, and closed protocol. and even when the protocol is opened up it's complex and can be changed remotely at any time in backwards incompatible ways.

back in the 90s and early 00s we had chat network aggregator clients like pidgin and trillian and adium. these were great: you could rely on something like libpurple (pidgin's underlying lib) and a community of devs would work hard to reverse engineer each network's complex protocol so that you could use a common interface everywhere. just humans sending text to other humans.

this has slowed down; libpurple doesn't enjoy the support it once did. maintaining all of these elaborate and constantly shifting proprietary protocols is fragile and exhausting. what if we put the onus back onto the chat network providers to give us a simple textual interface for lowest-common-denominator chat? what if we could divorce the chat protocol+network from the chat application?

the dream

what if each chat network responded to a simple text interface that let me authenticate and chat with any other user in that network?

  1. client implementations become trivial
  2. users can opt out of annoying / bandwidth expensive / undesired features
  3. it's possible to write a thin layer on top that lets me say "open a chat with noffle" and not care how the machinery underneath works

    chat endpoints become agnostic

all you need is a. an identifier for the message recipient and b. a transport, and human<->human chat is possible. of course classic chat networks (irc, slack, xmpp, skype, hangouts, facebook) but also abstracted over async media (email, usenet, scuttlebot, ipfs) and more!

the steps

let's define the bare minimum API for doing human<->human textual chat, and start integrating it everywhere. no more complicated ad-hoc chat protocols for each service if you just want to write and receive text to/from another human (or bot) on that chat application's network.

  1. let's make it unix-friendly: text based, newline delimited, highly readable to humans and very debuggable
  2. let's make it transport agnostic. all we need is a text duplex stream and we're good to go
  3. let's make it a standard, so it's well defined and enables de facto implementations to begin today
  4. let's make it so easy to implement on the server that big companies will have minimal defense in refusing to provide it

    adoption

    how do we convince chat program X to add and support ubc?
  5. engaging in honest communication about what their users want
  6. a well written and very coherent specification
  7. offering quality PRs, and
  8. an excellent test suite

once (2), (3), and (4) are done we write PRs for interested open source chat networks (IRC, XMPP, orbit, etc), to build momentum and get the community making client apps for desktop, web, mobile, etc.

hackergrrl commented 7 years ago

Thinking on this more, this idea can be likened to the web: device capabilities vary wildly, and a loosely coupled spectrum approach works better than a rigid one. As Resilient Web Design says regarding approaching web design:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

This might sound not unlike XMPP. It's similar! Provide core functionality for everyone, and let others include non-critical enhancements that appeal to them on top. XMPP didn't manage to get this right, but I think this may be because too many deep assumptions were included in the core that didn't map to the real world well (TCP-only instead of abstract streams; persistent connections rather than offline-first functionality; likely more!).