1. 43
  1.  

  2. 12

    What is the usecase for “transient chat”?

    I think IRC is in decline because of the lack of server-side backlog, and if we see what is popular/successful we can see all have server side backlog. Why is it this way? Because users need this functionality: it is needed for roaming/mobile phone usage, for example. If they wouldn’t need it, there would be no bouncers and other duct-tape solutions for IRC.

    Personally I think this protocol likely won’t have widespread adaption, because it is not substantially better than IRC, which some die-hard still use (sometimes I also do), but it won’t be usable to solve actual daily user needs, that is persistent-chat, which would be needed for adoption.

    edit: typos removed, some reordering of subsentences

    1. 4

      Yeah, this doesn’t really gain much over IRC, in exchange for the protocol encoding complexity that makes it nicer to implement in real-world implementations at the expense of toy implementations. (I tend to think the sake of Gemini too, so it’s nothing personal.)

      1. 2

        The main use case for “transient chat” I can think of is either implementation simplicity, or maybe security (ie you don’t want the server logging your conversations). Now that I think of it though, security would be hard to prove, so I suppose it’s mostly just simplicity.

        The option for server-side backlog is there, just not really fleshed out and implemented yet. Partially because I wasn’t sure whether it would be worth the trouble. Sounds like people consider it a killer feature though, from this and other threads.

        …darn it, now my brain is going “actually that would be kinda cool to implement”. In my deliberately-simple implementation I wouldn’t want channel log files that need some kind of handling, and I sure wouldn’t want a database, but an in-memory ring buffer of the last 1024 messages that have been sent in a channel or something like that might be a nice middle point between “useful” and “simple”…

        1. 5

          I’d be the last person to argue against simplicity, but consider that I’m an user:

          What is the use case (not serve case!) of transient chat? As a user I don’t care if the server implementation is complicated or simple. What I care about as an user is: does it solve the usecase I have?

          I still couldn’t come up with any usecase where as a user it would be beneficial or at least acceptable for me to chose this solution over a persistent chat solution. Maybe I’m spoiled forever by tasting the forbidden apple of Telegram and the likes?

          edit:

          So it is nice brainstorming, and I’m quite sure you’ll make a nice protocol out of this eventually, but if it doesn’t get adoption this will stay only as an exercise for you, with you being the sole user. :(

          As a user I’d like to chat with others, and getting others onboard to use this protocol is hard with the slogan: the server implementation is simple. I use 5-8 chat platforms on a daily basis, and I’d not be eager to get on yet another one if someone asked me… I don’t communicate with some ppl I can reach only over IRC, because we’re not online at the same time, and I don’t want to pay to be able to get the basic service I get from other chat services/protocols for free (may that cost be hosting/install cost/service fee, setup hurdles of clients with use with a bouncer).

          So I find this a nice toy project, but nothing more, until someone tells me a usecase where this dated approach is okay.

          1. 2

            I’m actually trying to think along those lines right now. I can think of cases when server-side persistence is not useful, but they’re not very common. I can also think of cases where the client software can do all the persistence for you and that’s fine, but I won’t lie, those use cases are also not very common. So, consider me convinced.

            1. 1

              I don’t want to ruin your project, and it still can be a nice learning project about lot of topics related to high performance network programming, just added my 0.02$ why I think it would be unlikely to break out from that stage.

        2. 1

          I think IRC is in decline because of the lack of server-side backlog

          IRCv3 solves this, for what it’s worth.

          1. 2

            It doesn’t look as if any currently developed IRCd’s support it, though

            https://ircv3.net/software/servers

        3. 7

          I like the idea of a minimalistic chat protocol, but this just looks like IRC with a nicer message encoding.

          Is there any way a simple version of Matrix could be done? Something that has a DAG of messages, so that netsplits can be reconciled easily instead of risking the usual netsplits? Seems to me that it’s simpler to federate this way if you can afford to content-address the messages (a bit like git, which is what Matrix does if I remember correctly).

          1. 2

            There’s an option of a message having an “in response to” field that is a SHA256 hash of the previous message, letting you form chains/threads of messages. Haven’t really explored the full implications of it, but two easy results would be a) being able to form an absolute (if not necessarily unique) ordering of messages, which would avoid some of the annoying things Discord tends to do on poor internet connections, and b) use the hash of a message along with the (currently vague) Catchup message to ask for every message replying to a particular one, so you can ask for “everything more recent than X”.

            Currently, yes, it looks much like IRC, because IRC is a pretty minimalistic chat protocol. :D

            1. 3

              IMHO “in reply to” should be used explicitly for threading purposes (as in “this message is a direct reply to a specific previous message”, regardless of if/how that’s rendered to the user). For general ordering, it’d be better to have a “last seen” field that has the id of the most recently received message from the server when the message is sent by the client.

          2. 4

            I am thinking about a chat system which takes advantage of Elixir. Run your own server, talk with it via ssh or web sockets. No protocols, no client/server, all state on the server. ssh to server for curses interface like irssi. ssh key for identity, Phoenix presence. Desktop widget talks ssh for notifications. Inline images by iTerm2. Server keeps state/logs, or not. Optional web interface. $5/mo VPS.

            1. 1

              How does this take advantage of elixir?

              1. 2

                Elixir is great for chat applications, as it can handle a lot of stateful connections. It has a built in ssh server library. Phoenix has great support for real time web apps and presence. If the app extends beyond a single server, it can scale to a cluster of machines. There is a reason that Erlang/Elixir are used for WhatsApp, Discord, ejabberd.

            2. 3

              Nice! As a chat systems nerd, I’m always interested in people trying to do something new in this space :)

              I like that a form of catchup is baked into the protocol from day 1 – being able to implement the equivalent of a message broker’s “durable subscription” is very valuable for not dropping messages on the floor (like in IRC where your connection drops). Minimalism is also a worthy goal – XMPP and Matrix do indeed try to promise the world, and are extensible enough that you can send anything over them, having a deliberately spartan alternative is a nifty idea.

              One thing that does seem lacking is any sort of discussion around how bridging to other protocols might work – would it just be a special case of s2s (as in XMPP), or would you design out a special extension for it (as in Matrix)?

              1. 1

                This is not a full federated your-server-talks-to-every-other-server type thing.

                There is no s2s. It seems it is meant to compete with IRC-ish c2s only and use centralised servers.

                1. 1

                  Yeah, because centralized servers are simple to do and relatively hard to break. And because I don’t know a whole lot about decentralized chat systems. Seems like with a centralized chat system you have to trust the owners/operators of the server your client talks to, while with a decentralized chat system you need to trust the owners/operators of every server your own server talks to.

                  Frankly, if I want to talk in the channel #foo@example.com then I see no reason to have to go through an intermediary home-server rather than just talk to example.com directly, and if you want a global topic #foo that any server can participate in then that seems Hard Enough I Don’t Want To Bother. And for bridging to other protocols, I’ve never seen it done well enough to be compelling enough to bother.

                  My mind may be changed on these points, however. Most importantly, authentication and any potential account metadata is decentralized, so no matter whose server you’re talking to, you can still own your own identity. (This part I HAVE thought about.)

                  1. 1

                    Yeah, because centralized servers are simple to do and relatively hard to break. And because I don’t know a whole lot about decentralized chat systems.

                    I’ve been idly wondering how one would do a decentralized chat system since I saw your sketch here. I think one would partition messages across peers with a distributed hash table, and have messages point to the most recent message posted in the chat/channel they’re in like you’ve discussed. That seems to lead to messages forming a DAG that we need some way of making eventually consistent, so maybe one needs some kind of CRDT for the messages? It’s fun to think about.

                    1. 1

                      For sure, except in a Global Network like original IRC dreams, chatrooms effectively end up being single-server. Though it’s useful as as admin to be able to choose the server my chatroom is on without requiring my users to connect to Yet Another Server.

                      If you have decentralized authentication/identity and account metadata (and 1:1 chats, if those are supported) then you are a fully federated type thing.

                      1. 2

                        Now O want to builds something like this (IRC) distributed and federated. Great, as if I don’t have enough unfinished projects.

                        1. 2

                          I’d love to hear your thoughts on design, to be honest. Like I said, I don’t know much about distributed chat systems, but learning more would be nice.

                        2. 1

                          The primary use case of multiple servers is for operators to be able to bounce instances or have some die without losing what might be an important piece of infrastructure. Anything else, including possible load sharing or ping time optimization, is at best a nice side effect.

                          1. 1

                            Right, sorry, I should be careful to say “centralized” in this context. Number of “servers” is a red herring

                          2. 1

                            Sometimes I wonder if federated is bad for implementations, but federated identity on whatever centralized/decentralized server we want is good.

                            1. 1

                              Like OpenID? That never took off. Nowadays Facebook is probably the largest identity provider online.

                    2. 2

                      Awesome. I had been thinking of doing something similar also in CBOR but looks like someone beat me to it! I’d be interested in contributing. Please post the announcement on Gemini also if you can :)

                      1. 2

                        Contributions would be welcome! This is really just me making a proof-of-concept to try to see what it looks like, and have kind of spent as much Code Fuel on it as I want to, at least for the moment. I’d be happy to develop the idea further though!

                        Posting to the Gemini mailing list… idk, I’m shy. If you think it’d be well received, sure.

                        1. 1

                          Posting to the Gemini mailing list… idk, I’m shy. If you think it’d be well received, sure.

                          Oh sorry I really didn’t want to apply pressure or anything here. It’s your project, do what you will with it! But thanks for the hard work and release!

                      2. 2

                        One consideration is differentiating between protocols. How, when I connect to a server, do I know it’s a scalar or IRC or XMPP server?

                        1. 2

                          port number?

                          1. 1

                            And if you choose a different port? Say 6767. Not IRC’s port, but identifying a protocol by its port is a great way to accidentally fuzz your parser.

                            1. 1

                              I’d throw nmap’s probing scripts at the port.

                            2. 1

                              port number.

                              1. 1

                                See my response to singpolyma