Quiet started as a "look before you leap" passion project to build some kind of FOSS and peer-to-peer online gathering space, but got serious about user research a year into the project and at this point might be the attempt at p2p chat that has the clearest idea of who its building for and what their needs are.

The talk will first motivate the problem by first describing our intended users (like reproductive justice activists in the US or news organizations in authoritarian contexts), their needs, and the friction points we've run into with our existing approach to building Quiet. (One which seems to mirror most other approaches, which we see running into similar issues.)

Then I'll cover the reasons I thought there might be a much easier way to build something like Quiet, what pain points we've run into building Quiet, how those might be solveable, and what the other advantages of a simpler stack might be (advantages like security).

Finally I'll run through a chronology of my/our attempts at building a better stack and list the lessons learned. There are a lot of them, and some will be really interesting to people working on this stuff. Some examples:

1. A better way to think about DAG structures than "new events depend on previously-sent and recently-seen events".

2. A cool and I think unpublished way to do set reconciliation on a small range ("today's messages") such that dependencies also sync efficiently (via Aljoscha Meyer).

3. A way to do forward secrecy for deleted messages that fits user threat models, most application types, and the peer-to-peer context much better than the "purge keys after decrypting" ratchets of Signal and MLS.

These are all fairly technical examples, but I'm passionate about them and will make sure the problems are all well described and that the talk doesn't get too dry for less technical folks. It will feel like a fun tour through problems and solutions, not a technical slog.