1. 30
  1. 8

    Unlike most intentionally-limited protocols like Gemini, I quite like this one. The idea of a federated network of little rectangles appeals to me. And I love Curve25519 and key-based identity.

    I am a bit disappointed by the arbitrary(?) limit of 2217 bytes of HTML/CSS without external resources. I would really like to see images, and I think this size is too small to allow much, since you’d have to express the image in base64 as a data: URL. While I recognize that one wants to keep the size down to avoid servers getting bloated, surely we can handle somewhat bigger sizes. You can store a million of these snippets in 2GB, which is peanuts. Why not 22170 bytes, or 221700?

    1. 5

      Yeah, I am curious as well about why that specific size, but he actually does explicitly talk about the size limit later in the introduction, and it has two interesting consequences/relationships:

      1. You can put 10M of these in <23GB. One upside to that: the storage for it will fit in the limits of every $5/month VPS service out there today, which makes it super cheap to run your own server.
      2. It comes with an upper bound of 10M active boards, ever: a move somewhat inspired by (but very different in implications from!) the artificial scarcity of blockchains.

      The other thing I’ve been mulling on is: one of the wins from “microblogging” is the creativity inspired by its limits. Limits are provocations to be clever! (I think often of Craig Mod’s essay Let’s Talk About Margins, now nearly a decade old.) That dynamic is in play a bit here—unsurprisingly, as that dynamic is one of the themes of Robin’s work in general.

      1. 9

        since a lot of implementations will probably store those snippets in individual files, you could raise the limit to 4096 bytes and not take up any more space :) Although you might have to subtract a few bytes for metadata.

        1. 1

          Can you really efficiently store 10M items as individual files on Linux (which will be the dominant server OS for this if it ever takes off)?

          My initial thought would be a database. Most accesses would be read requests from clients anyway.

          1. 1

            I don’t know anything about the innards of Linux filesystems. I would hope that by today they’d be able to handle large directories efficiently, but you never know. A common workaround is to have two or three levels of hierarchy, e.g. 3000 directories each with 3000 files. That’s what Git does, for instance.

            1. 1

              Yeah, these are implementation details. But having one file per entry does lead to a lot of overhead if the byte limit is strictly enforced. I’d not be surprised if authoring clients did all sorts of minimization tricks to get as much into an entry as possible, and in that case servers can leverage that by storing the data in flat files for easy indexing and retrieval.

    2. 7

      I actually run a qotd service [1] and learned the hard way why one should implement the UDP version—it’s all too easy to use it as an amplification attack against a target. It took me a while to figure that out too, unfortunately.

      I find it interesting (much like I found Gemini interesting enough to write a server, but I think for this one, I would have to see it in operation first. (And edited to add): maybe the author should also read up on NNTP, as this seems eerily similar to that.

      [1] nc conman.org qotd for those interested. It’s not quite RFC-865 compliant as I do have quotes larger than 512 bytes, and the line endings are just ‘\n’ instead of ‘\r\n’ but other than that, it’s not a complicated program.

      1. 5

        I think you meant “should not implement the UDP version.”

        This protocol’s overlap with NNTP is that they both gossip, but the content models and authentication (or lack thereof) are completely different.

        1. 2

          You are right, I forgot the “not”. Thanks.

      2. 2

        This seems fun, and I like many of the tech choices, but if doesn’t feel… Useful? Like, a grid of stuff that might of might not change? If it doesn’t change, why am I looking at it? If it does, why don’t I want history?

        1. 3

          From my read of the intro and the spec, there’s nothing to prevent the client from keeping track of state and/or history in a local context.

          1. 2

            I imagine you’d have a big enough grid such that some bits would always be changing on a daily or hourly basis. It’s something you could pop open for a brief info-snack, but the design discourages endless surfing/scrolling. (I was going to write “prevents”, but the items can have links and you can click them and wander off from there…)

            It also seems like a great application for an always-on ambient display in a spot that you walk past. Kind of a non-purposeful version of those greenboard displays teams put up in offices.

            1. 2

              I don’t get how this should not encourage me to refresh it all the time and manually look for updates?

              Maybe I’m the odd one out with my RSS-inbox-zero habits, but I really like that I can open my news reader, check everything from site X”, and mark all as read - done. This feels like “having to visit several times per day/week again, just the opposite of RSS and a state of “done”.

              1. 2

                This is a thing clients can implement differently. A client could have a “new boards” mode or filter, or show random boards you’re subscribed to algorithmically, or any other presentation design you can come up with which matches the spec (which, interestingly, implicitly excludes ‘crawling’: the spec draft forbids listing boards).

                1. 1

                  Yeah, it’s a different mindset. I’m the same as you with RSS, but I think of this more like tumblr, which I can (could) visit periodically for a snack instead of feeling like I had to catch up on everything.

            2. 2

              I’m not sure Robin wants this shared on social media yet. It’s still in the ideation phase. See https://www.robinsloan.com/lab/specifying-spring-83/

              1. 4

                Exact quote for other folks (who should feel free to agree with Carl and disagree with my choice to share in a few places):

                It’s okay to share this link, but I want to underscore that I am sending it specifically to you with the hope that you will … really think about it! At such a primordial stage, a proposal like this doesn’t need diffuse, drive-by attention. It needs, instead, close consideration and generous imagination.

                I took putting it here as being in that spirit but could see it the other way too!

              2. 1

                I do like the general idea (a Pinterest-style display of snippets from people you follow), but there’s a whole lot of other stuff I don’t care for. I don’t like the hashcash-style mechanisms to make it harder to generate keys, and to limit how many feeds a given server network carries; I get that the idea is to avoid spam/abuse and to limit server resource consumption, but this just seems like a bad way of doing those kinds of things that could have unintended consequences (like the whole keyspace on every public realm is snatched up by cryptoscammers). Also, other than “start posting without registering an account anywhere”, I don’t actually see how this has many advantages over, say, a specialized RSS client.

                1. 1

                  I had a meeting this morning in which we review end-to-end tests that have been skipped. This list is ephemeral and I never care about the history. This protocol would be perfect for automating and distributing this list. Which could actually live along side other test information boards.