Comment by austenallred

11 years ago

There have been and always will be competing products and communities that serve similar purposes. We use what we think is the best one. Is this a bad thing?

(Not to mention the fact that Slack is for internal teams, not for IRC-like discussions, though our open newsroom (http://newsroom.grasswire.com) and some other communities (http://fpchat.com) have repurposed it for that.

4 comments

austenallred

Reply
inopinatus  11 years ago

I think that "best tool for the job" attitude is a straw man. It seems to presuppose that "the job" is per-organisation, or even that there is one job.

In truth many of us believe that the goal is enabling everyone - universally - to communicate without a single body holding centralised control of message history, reachability and access.

Quick review of the globally federated protocols:

  Email is too slow and bulky and lacks "group" capability
  IRC is deeply unreliable and lacks identity, archiving, and media management
  NNTP is too amorphous, slow, and lacks any privacy or security controls
  Everyone thinks SIP is just for telephony (it isn't)
  XMPP is phenomenally complicated yet held great promise
    - if only everyone could agree on the extensions and semantics.
    - but was murdered by Google.

  • e12e  11 years ago

    You forgot h.323. On the surface, it looks to me like a "saner SIP", or XMPP with working, standard audio/video support -- but I might be wrong.

    I'm not sure why people claim IRC lacks archiving support. Isn't a bit like saying SMTP lacks archiving support? And doesn't basic IRC always go through a server? So there shouldn't be any technical barrier against a server archiving all chats (private and in channels)?

    As for NNTP, I'm not sure if NNTP over TLS, peering with only trusted sites (aka for internal use) would make sense or not. I never did use Usenet much. At least the D language forums have made an effort to bring NNTP into the www era[d].

    It's interesting that no one seems to do a decent job of (server side) archiving for XMPP -- partly I think it's because as you state, the XEPs have gotten out of hand -- and partly XMPP appears to be especially popular for users that want privacy -- and treat ephemeral chat as a feature.

    [d] https://github.com/CyberShadow/DFeed

    (format note, you probably should've just listed the protocols in separate paragraphs, as indented blocks with lines longer than ~50 characters doesn't format very well on hn).

    • inopinatus  11 years ago

      Good thought re.H.323, it is often forgotten in these discussions, in part because many implementers resent binary protocols and the ITU has few friends outside the telephony world. https://www.packetizer.com/ipmc/h323_vs_sip/

      The IRC protocol is neither sophisticated nor scalable enough that we can all federate our private trusted IRC servers. IRC services are severely limited by being a brittle undirected acyclic graph of servers with little but text forwarding in the protocol. Trying to do anything sophisticated like e.g. identity management, is an ugly business.

      NNTP has no identity scheme and no private channel. Running it over TLS doesn't change that. You can forge an ersatz private channel with encryption (I once did so, using Usenet as a message queue to backhaul out-of-band service alerts) - but it's neither pretty nor grandma friendly.

  • austenallred  11 years ago

    No, it presupposes that there is a defined task.

    I suppose the difference between our points of view is that I would much rather have a better tool than a publicly accessible archive of message history.