Linkability is a really big deal. You can get it with IRC if you keep public logs, but getting a link is definitely harder than if you have a fully-integrated system like Zulip, as there’s no standard way for the client to sort it out.

At FastMail with our group email system Topicbox, we put a link to the archives for the current email in the mailing list footer, and that’s the favourite feature of quite a few of us in the company, and we’ve heard similar from our customers too. (Not sure why Mailman doesn’t do this, it’s super useful.) This gets around the need for a single frontend. Something IRC-like could work that way if each line sent included a URL, e.g. in JSON {"speaker": …, "url": …, "time": …, "text": …}. I have no idea at all if the likes of Matrix can or do work that way.

You get bonus marks on a feature like this if it includes meaningful content in the URL, e.g. Zulip’s URLs, although a tad ugly, include the stream (a slug) and topic (slightly weirdly encoded rather than slugified, but still present and readable). That way I can look at a URL and have a fair idea what I’m getting myself into. (URLs are definitely UI.)

Here's a link to a specific matrix-message: https://matrix.to/#/!QtykxKocfZaZOUrTwp:matrix.org/$15515574...

> Not sure why Mailman doesn’t do this, it’s super useful.

I believe this is because mailman doesn't have an integrated archive - it would have to ask hyperkitty (or pipermail etc) for an url to include in the outgoing message.

I'm sure it could be changed, but probably reflects that mailman is "mail first", for better or worse.

All it needs to work is a field for a URL template, and for the archive system to have sane URLs. Pipermail URLs don’t correspond to anything in the email, so the simplest imaginable integration would entail an additional entry point like /lookup?list-id={listId}&message-id={messageId} which would redirect you to the page for the right email.

Granted, this is really bad when compared with an integrated archive, but it makes it at least possible. You could easily then go on from there to automatic configuration for specific archive systems.

URL isnt necessary just a UUID / GUID as part of the message structure that the server then maintains track of. But I dont think most servers care about logs in a structured way.

An ID for a message is sufficient iff there is a defined, deterministic way to turn it into a URL. In the case of an IRC-like protocol, that would mean that you needed a defined URL structure, or a defined way for the server to give a URL template to the client.

> I find it helps us have real discussions, as compared to other types of forum (and I've tried a bunch).

Have you tried a modern forum, like Discourse? I'm trying to understand why many open source projects opt for chat platforms instead of a forum. Why are you resignating public and search engine accessible discussions?

Overall, I find Discourse really annoying. It has some good stuff in it, but it just tries to be too clever, replacing standard techniques that play well with web browsers with its own magic that is simply nowhere near as good. Its lazy loading story, for example, is extremely weak. (I don’t know if it’s better with 25ms latency rather than the 250–350ms an Australian will always get on such things which are invariably hosted in the US, but I don’t expect it’ll be good even there.) Just load and render the entire thread, please, and then don’t hijack Ctrl+F.

Discourse is also very wasteful of space for anything but long-form prose: a single line of text is 180px high (in other words, a typical screen will never under any circumstances fit more than five comments on the screen at a time), and a single-line quote from someone else adds 80px. Compare discussions here on HN with Discourse. I’d much, much rather work here. (Yes, their purposes are somewhat different, especially as regards ordering; and applying the HN structure to longer-term discussion would require changes of some form, because it wouldn’t work if you just took it verbatim.)

If I had infinite time, I’d write a leaner frontend for Discourse with much less magic and much less wasted space.

I have used Discourse quite a bit, and it was a top consider when we were looking for a new platform.

Public web archives are a goal, and either we'll deploy a bot to publish them, or I've heard rumors this feature may be added to Zulip itself.

In the meantime, it's kind of nice not having everything immediately publicized. We've had (knock on wood) exactly zero problems with spam users, even though it's open to everybody with a Github account. I'm also (if temporarily) enjoying the freedom to talk a bit more intimately, for example I'm discussing a major project I'm considering taking on.

Public archives is definitely on the Zulip roadmap; much of the preparatory backend work for supporting was merged last year.

One thing I'd be interested in feedback on is how folks would feel about an ugly/janky version? There's a few different versions we've talked about:

* Being able to use the main Zulip user experience, with "public user" data (no unreads, can't send messages, etc.). This would be best as an actual browsing experience.

* Having a totally new webpage that's mostly just HTML+CSS (better for search engines) similar to our digest emails.

Possibly we'll eventually do both, but I'd love feedback on which of these open source projects care about the most.

(In any case, it'd be configurable at the stream level, so you could have some but not other streams that are public in the organization be publicly archived; we already have the data model for doing that).

Of these two, I find the second more appealing. The main use cases I have in mind are linking discussions from issues, and in general creating a permanent record of the work we do (our IRC logs got lost, I should have been on the ball to preserve them).

For people who actually want the Zulip experience, I have no problem just asking them to sign up for real. Since we have open signup based on github login, it's a pretty small barrier.

I think (2) sounds more useful too. You may also wish to consider a 3rd option: a machine readable export format (XML?), which would allow users to make their own human-readable archive formats.

That's already easy to do with the Zulip API.

I think people feel more comfortable in chat than a forum. People often feel hesitated to ask simple questions on forums thinking it's stupid. Plus forums take too long to reply.

It's often better to have both, I think.

I agree, I actually built that, I mean, a chat + forum at the same time. And it works in the way you said: people post quick informal questions in the chat, and longer more "serious" questions in separate topics. https://www.talkyard.io

chat(slack etc) is real-time basically, forum is not.

the best will be chat+forum, and support mailing list style digest, also support post-by-email

Then you might want to check out Talkyard, it is chat + forum. https://www.talkyard.io (I'm developing it). A bit like a Slack, HN, Discourse hybrid. Post-by-email is planned.

Looking good, but please, don't make me click on the small area that is the title of a post to see the content.

Ok, thanks for the feedback. (You had in mind the topic titles, in the topic list, right? And you'd prefer the text excerpt, below a topic title, to also be clickable and link to the topic, right?)