51–60 of 225 posts
Why isn't encryption baked in by default? It's optional from what I can tell. I don't know how you can design a new protocol and not include encryption.
Exactly what I wanted to say. Why even bother if encryption is not included by default in the new protocol?
I second a comment made below regarding https://matrix.org/ . I've used IRC for years and still use it almost daily - but come on Mosh + tmux + ec2 just to have permanent chat history? I seriously can't advocate this crap to anyone in 2016. It's too little, too late.
Earlier quoted context omitted.
Eugh. You could at least choose an open standard like Matrix. http://matrix.org/
Why?
Also, in this particular case, Matrix also appears to be a well thought out platform for decentralised communication, one that is likely to be flexible enough to meet the needs of multiple different forms of communication.
However, I don't really understand how reposts work. I always thought that URLs are a unique key.
Is this a way to kind of "retry" them? In this case I'd be curious about how they work.
Earlier quoted context omitted.
> Are irc clients supposed to magically redraw the buffer and edit logs??! Who speaks about magic? Just send a message with the original ID and make the difference. Mark it in the UI, and redisplay it.
So logs are no longer append-only? This seems like a uselessly complex thing for all servers and client logs to support. Seems like it would break many things. What situation needs an edit feature? I can think of none, since a quick follow-up correction is simple. Also, edits would ruin many of the funny situations encountered on bash.org. :)
Earlier quoted context omitted.
So logs are no longer append-only? This seems like a uselessly complex thing for all servers and client logs to support. Seems like it would break many things. What situation needs an edit feature? I can think of none, since a quick follow-up correction is simple. Also, edits would ruin many of the funny situations encountered on bash.org. :)
We use Slack heavily in our organization and editing happens all the time - whether it's to fix a typo, or insert a missing word, or cross out something we wrote earlier and put in the corrected version. Once you can do it you'll learn the value of it.
Once you try it, you never want to go back.
My favourite bit is how they skipped adding length negotiation and it is causing them problems already. See the brief discussion of size limit on http://ircv3.net/specs/core/message-tags-3.2.html Adding tags forced them to increase message length because of how IRC messages are hilariously limited to 512 bytes in all directions. In the existing protocol you already have to guess how long your messages are allowed to…
Imagine user A negotiates a length fo 1024 bytes with the server, user B negotiates a length of 2048 bytes.
User B sends a message via the server to user A.
What happens?
Interesting development. Apart from the original IRC specification published in 1993 and revised in 2000 (supposedly the namesake of "IRC v3") there has been quite little real standardisation work in IRC protocol, with various clients, servers and platforms each implementing their custom extensions.
Related, I've been working on these sites for a while which I hope can be useful: http://defs.ircdocs.horse/ http://modern.ircdocs.horse/
Still, it's been really interesting to get into. It's nice seeing how things have gone so far and how they're going forward (and digging into the archives is always fun).