quiet VS diamond-types

> because, right here right now, that is such a hypothetical situation that I have absolutely no idea why it needs a real-world demonstration of proof of concept using currently-available technology.

So I just want to point out that IPFS was fairly deliberately designed to have numerous, forward-compatible features that could be swapped out in the future : like https://multiformats.io/ and in particular https://multiformats.io/multiaddr/ .

In the IPFS community, there's always been a fairly heated discussion about which bit of the entire system should be stuck with the term IPFS. Like, if you took away the libp2p protocol, and just served CIDs over http, would it be IPFS? What if you took away CAR files (the merkle-tree file format used to define multi-item content)? What if you're a private IPFS network, with no shared nodes with the public network (like https://github.com/TryQuiet/quiet ). What if you didn't use bitswap, the file transfer protocol (Filecoin doesn't use bitswap, and mostly doesn't interconnect with the main public IPFS network). What about if you didn't use a DHT to find providers of a CID. What if you're not using any of the "IPFS" software stack, but your implementation still uses bits and pieces of content-addressability as defined in the standard?

Interestingly, right now, there are a bunch of experiments going in all of these directions: I think it's fair to say that if you wanted to test out content-addressable networks across the solar system, they probably wouldn't be IPFS as it is now, but their nature could probably be described using the primitives the IPFS stack uses, and learning about what needs to change would give a useful direction to some part of the extended IPFS ecosystem.

Their website is at https://www.tryquiet.org

> do you have an individual username for each community, or will your profile eventually be the same across all the communities you're in?

We're starting with names specific to each community, since that is simplest/cleanest and best for privacy.

> profiles you can customize to servers can be useful, so long as you can still trace them back to the user's actual profile. otherwise that might enable masquerading as other users

There are some decentralization-friendly ways you could link your profile to other profiles, like a Discord or HN account. tlsnotary.org is one example. Would that be good for preventing masquerading?

> users able to mark as invisible (appearing offline without actually being so)? good to have in many situations imo, obscuring information from people who may be a danger to you

we do plan to do this, but it's some complexity to really hide it from a tech-savvy malicious user, so the first version of invisibility will be weak and we'll tell users this. Here's the open issue and there are links to proposed designs in there if you'd like to give feedback! https://github.com/TryQuiet/quiet/issues/1504

> how is name collision handled? in a large community, you're bound to have a few people who want the same name (and i get it, your screen name can be very personal) discord's old solution, a username and 4 digit id (e.g. felix#1234), seemed convenient and effective to me, but there must be tons of solutions; i like having a way to easily distinguish two users with the same screen name

we're not allowing name collisions for registered users. in the coming release there will also be unregistered users who will have a badge until they register with the community owner. if the community owner lets registered users' names collide we treat that as an impersonation attack and warn everyone. since names aren't global you'll usually be able to get the name you want!

> personally blocking users you are uncomfortable interacting with, kicking users from communities vs. banning repeat offenders in a more permanent way, temporarily muting a spamming user? kicking vs. banning can be an important distinction; i'd rather kick you if you're just inactive all the time, you're free to rejoin whenever you like

we don't have user removal yet but obviously that's a big priority for us.

since we don't have usernames, to ban somebody you would kick them and reset the invite link. blocking and muting and silencing people will all be very straightforward. as will roles and other kinds of moderation, and external identity linking would be helpful for this too. you'd be able to make someone link another profile and approve who you are letting in.

> i like keeping it very, very clear what does (or does not) happen when you block, kick, ban, etc; a user shouldn't have to "test" features like these

this is a great note, thank you!

> important to keep in mind that you rarely (or never) want a user to completely disappear; i always want to leave the option to get back in touch, unban, unmute, etc.

hmmmm. this is an interesting and cool idea I have not run into before. yeah, unban and unmute are possible.

> a friends system is useful for this; maybe i don't want anyone i haven't marked as a friend to DM me

Our first plan is to not allow DMs at all outside a community, but there are some ways we could do this.

> selectively muting different portions of the app (e.g. i only want to be notified of a DM or @ mention, or only notifications from this community, or no notifications from this channel except @ mentions)

this is planned, and thanks for the details! Here's the issue for channel notifications: https://github.com/TryQuiet/quiet/issues/623

> what if i want to be notified whenever this phrase pops up in a community? might be a question of how easily you can build your own scripts on top of Quiet (which i would quite like to do)

i'd love to enable this someday but we have no immediate plans to. but it is one exciting thing about a fully user-controlled app: you can give users a lot of flexibility. Imagine a team chat that was as flexible as Wordpress!

> are voice and/or video planned, both in communities as well as dms?

yes, but I'm not sure if we'll do unlimited group calls for free, since we'll need servers for this piece so it's a natural place for us to charge money (we'll need to). And I don't really have clear plans for how voice or video will work yet, since it's far off.

> i've seen many communities in other applications where multiple "owners" existed, as it can make a more safe/welcoming community. if one owner in any way becomes untrustworthy, having someone with equal permissions in place to get rid of them and undo damage can help; whether they can remove each other or not seems like an important decision

yes, we'll allow multiple owners at some point, though the naming role will belong to one user. https://github.com/TryQuiet/quiet/issues/1758

> question about the threat model; members are not capable of sending messages that appear to be from another member, which implies that owners are capable of this? that could become a serious issue if true

this is an issue right now yeah. what we can and will do very soon is show an aggressive warning almost immediately in most circumstances if this happens. see: https://github.com/TryQuiet/quiet/issues/119. but there are edge cases where spoofing could happen that are hard to reason about or convey, so it's unlikely we'll fully address this weakness soon.

> user discovery outside of communities, preferably just typing in a username they send you elsewhere?

Global naming features like this exist in tension with decentralization, unless you make people pay for usernames, which isn't a great experience.

> will it be possible to delete an entire community? can an owner do this in situations where members don't agree?

Yes. A member could block deletion by not going online or by modifying their Quiet app, but deletion is important enough for activists that we want to make it easy. Maybe this is a setting on the community level or user level.

> searching channels (and more advanced searches; sent by this user, with an image attached, in this channel; hopefully accessible to users even if they can't do regex on the fly, lol)

we'll definitely have search but don't yet!

> i've found it frustrating not to be able to search every community i'm in at once for something i said; is that feasible?

yes! it's all on your computer so totally feasible and this is a helpful note! i feel this way about email all the time when using gmail so I get it.

> any distinction between a community and a DM with 3+ users in it?

DMs will exist within a community; a community is at the level of a Discord server, e.g. We're not planning to do the Slack thing of giving ad hoc group chats their own special status, but 1:1 DMs will be special probably.

> dark mode, and in my opinion, ideally a way to customize everything more thoroughly. if thorough customization, maybe a way to save/export those settings to share?

We already have designs for dark mode: https://github.com/TryQuiet/quiet/issues/1502. what app or site does customization great? what approach can we follow, if any?

> maybe the ability to see separate messages sent in a row - is that a message in 3 lines, or 3 messages? just hovering and seeing one line highlighted (and the timestamp for just that line)?

these two things drive me crazy too! See: https://github.com/TryQuiet/quiet/issues/505 & https://github.com/TryQuiet/quiet/issues/1403

> embedding video and audio files in a convenient manner? replying to messages, pinning them to channels (so they can be easily found again) seem very useful

we'll definitely do this!

> channel organization and categories; i don't always want the art channels open, i want #announcements at the top, etc.

Cool, I'll make an issue for this!

> messages marked as read/unread can be useful, something to carefully think about. client side unread; i'd like to pick up from the last message i read in this channel

we have a floating "unread" notification but there's more on this to do!

> sometimes i like knowing that someone has read my message; sometimes i like the safety that comes with people not being able to know. if i had to pick, it'd be the latter, users can always prove they have read something by responding to it

We can do either but now we don't show who has read your messages, with the same caveats as above about strict invisibility of your online status being tricky.

> keyboard navigation beyond pressing tab is super useful; a screen you can reach to describe these shortcuts is equally so

Yeah! Ctrl-K works right now for jumping to channels but we don't make it discoverable enough.

My team is building Quiet, an alternative to team chat apps like Slack and Discord that works as you describe:

https://github.com/TryQuiet/quiet/#readme

> Granted, sending a message would require all parties to be online at the same time, but there could be a set of relay servers to hold messages until they get fetched.

We actually do a bit better than this! We use a gossip network (libp2p gossipsub) so all peers don't have to connect directly, and a CRDT over a private IPFS network so that everyone in a community eventually syncs all messages. As long as there's a continuity of online peers, the availability of messages is the same as a central server, and with a few Android users in the mix it's pretty easy to get to that level of continuity.

(The battery impact of staying connected all the time isn't as bad as you'd think, and we haven't even begun to optimize it.)

And yes, it builds on the maturity of Tor rather than trying to roll its own onion routing layer as Session is doing.

> I think far more interesting these days would be projects like Veilid, Hyphanet's Locutus

I have not assessed Veilid yet but it's on my list and at a first glance seems like a very serious and informed attempt. I'm personal friends with Freenet / Hyphanet's Ian Clarke and spoke with him about Locutus when he was just getting started. It sounded awesome then and I will give this a second look too, though when he explained it to me it sounded like it had the same limitations with deletion that Nostr or the global IPFS network would have. It does seem important to note here that both Veilid and Locutus are much less mature and battle-tested than libp2p and Tor and have less Lindy longevity (longevity as a function of age.) We already suffer a lot from being on the bleeding edge, so it's nice to limit the number of bleeding edge tools we use. Libp2p, notably, has been rock solid for us and barely a time drain at all, apart from some unexpected interactions with Tor which are mostly about the lack of an official first-class Tor transport, which is specific to our use case and should start to change soon when Tor's Arti is ready.

> and ultimately Nostr -- even though not truly P2P in that sense -- which already happens to have a first try going with nostrchat.io.

Nostr and Bluesky both seem very promising for the open-world use case of social networking, and it has been amazing to see Nostr grow so rapidly as a community. I am rooting for this project and we might use it someday in Quiet for public feeds. Timed deletion is the user requirement that drives me away from building Quiet on Nostr. Based on conversations I've had with users doing sensitive work (and based on my own experience as a founder of Fight for the Future) timed deletion is extremely important to team security, and for deletion to be meaningful one needs more control over where the data is relayed than what Nostr provides in the default mode. A group that wanted trustworthy timed deletion would have to control their own private Nostr relay. Technically, a Tor relay could subvert the timed deletion of some Quiet messages just by capturing all traffic, but this is much less of a worry.

> If P2P is something that is truly desired, I feel like projects like Briar (https://briarproject.org/how-it-works/) have solved this with Bramble (https://code.briarproject.org/briar/briar-spec/blob/master/p...) more eloquently than it could be done on top of IPFS.

Bramble could work for us and I would recommend that anyone look into it. Briar is probably the most similar thing to Quiet that exists right now. There are big differences between Quiet and Briar, but we could definitely build Quiet on Bramble if it adequately supports iOS. My worry would be its maturity as a tool for people building things other than Briar. That could be worth the risk though and I do recommend anyone else reading this thread look at Bramble if you are doing something similar.

> I could nevertheless imagine it being overtaken fairly quickly by other projects sporting a rather lightweight and more managable basis, that allows for increased development speed and ultimately for faster iteration on features that users might wish for (e.g. DMs, @-mentions, message deletion, mobile clients, you-name-it) -- without the need to invest heavily into e.g. performance (or reliability!) issues of the underlying framework.

This is definitely something we will keep an eye on, and thank you for the thoughtful advice! My guess is that as soon as we have a significant number of real users we will need to build things that don't happen to be supported by whatever stack we choose (whether that is our current stack, Bramble, Veilid, Automerge, etc.) So the question is what's the easiest one to maintain and adapt. So far libp2p and IPFS have both been good in that department: implementations in many languages, active development, an absence of major problems showing signs of maturity (especially in libp2p), etc.

Also, my 2 cents are (for anyone following along) that if I had to do this all over again I would use Tor + Libp2p + Automerge. Libp2p and Gossipsub are solid, flexible, and will be around a while. No need to reinvent the wheel. The conceptual framework behind Automerge and Briar/Bramble are pretty similar (sync state!) but the Automerge team exists to serve people building other apps, while the Bramble team mostly focuses on Briar AFAIK. What's nice about Automerge is that the community around it (Ink & Switch, Martin Kleppmann, and other academics) is all at the academic frontier, so the level of thought and anticipation of user needs that goes into their decisions is very thorough, even if the implementations lag behind the papers. If I was doing real-time text I would also look at the Briar project and Seph Gentle's work on Diamond Types, since that's where the most thought has gone into the raw performance you need for text CRDTs that can handle large documents: https://github.com/josephg/diamond-types

But I think thats about it. Maybe there's more manually specified types in "normal" rust because most functions are smaller than that. But, it doesn't feel so bad. In this case I could probably even remove the explicit type annotation for that queue definition if I wanted to, but it makes the compiler's errors better leaving it in.

[1] https://github.com/josephg/diamond-types/blob/66025b99dbe390...

diamond-types (for reference for others [0]) still only supports plain text, is that right? I was thinking of using it for more general use cases such as an offline habit tracker, which isn't text of course, but I was interested to hear more on the progress towards other data types such as generic JSON data.

Currently for this use case I've been using autosurgeon [1] so far which has a nice Rust API for structs, even if it might be slower than yjs (or yrs, its Rust implementation) or diamond-types.

[0] https://github.com/josephg/diamond-types

[1] https://github.com/automerge/autosurgeon

I'm working on a CRDT to solve this problem too[1]. How do you plan on implementing collaborative text editing on top of your event-reordering system? Off the top of my head I can't think of a way to implement text on your proposed system which would be performant and simple.

[1] https://github.com/josephg/diamond-types

For example, this file implements a complex iterator via a struct and really complex next() method. This file was about 1/3rd the size before I manually rewrote it into a "continuation passing" style. I find it significantly harder to read and maintain in its current form.

> In this case, the bottleneck at 9 million LoC is not CPU cycles but memory usage. That's where I am considering pushing down into WebAssembly

How often does this come up in practice? I can't think of many files I've opened which were 9 million lines long. And you say "LoC" (lines of code). Are you doing syntax highlighting on 9 million lines of source code in javascript? Thats impressive!

> I guess my point is why do you need balanced trees? Is this a CRDT specific thing? Can you implement CRDT with just an array of lines / gap buffer?

Of course! Its just going to be slower. I made a simple reference implementation of Yjs, Automerge and Sync9's list types in javascript here[1]. This code is not optimized, and it takes 30 seconds to process an editing trace that diamond types (in native rust) takes 0.01 seconds to process. We could speed that up - yjs does the same thing in 1 second. But I don't think javascript will ever run as fast as optimized rust code.

The b-tree in diamond types is used for merging. If you're merging 2 branches, we need to map insert locations from the incoming branch into positions in the target (merged) branch. As items are inserted, the mapping changes dynamically. The benchmark I've been using for this is how long it takes to replay (and re-merge) all the changes in the most edited file in the nodejs git repository. That file has just shy of 1M single character insert / delete operations. If you're curious, the causal graph of changes looks like this[2].

Currently it takes 250ms to re-merge the entire causal graph. This is much slower than I'd like, but we can cache the merged positions in about 4kb on disk or something so we only need to do it once. I also want to replace the b-tree with a skip list. I think that'll make the code faster and smaller.

A gap buffer in javascript might work ok... if you're keen, I'd love to see that benchmark. The code to port is here: [3]

> Undo support -> In which case, you only have to stack / remember the set of commands and not have to store the state on every change. I'm not sure if this overlaps with the data structure choice, other than implementation details.

Yeah, I basically never store a snapshot of the state. Not on every change. Not really at all. Everything involves sending around patches. But you can't just roll back the changes when you undo.

Eg: I type "aaa" at position 0 (the start of the document). You type "bbb" at the start of the document. The document is now "bbbaaa". I hit undo. What should happen? Surely, we delete the "aaa" - now at position 3.

Translating from position 0 to position 3 is essentially the same algorithm we need to run in order to merge.

> I was just looking into TypedArrays.

I tried optimizing a physics library a few years ago by putting everything in typedarrays and it was weirdly slower than using raw javascript arrays. I have no idea why - but maybe thats fixed now.

TypedArrays are useful, but they're no panacea. You could probably write a custom b-tree on top of a typedarray in javascript if you really want to - assuming your data also fits into typedarrays. But at that point you may as well just use wasm. It'll be way faster and more ergonomic.

[1] https://github.com/josephg/reference-crdts

[2] https://home.seph.codes/public/node_graph.svg

[3] https://github.com/josephg/diamond-types/tree/master/src/lis...

Hi everyone! Author here. I'm happy to answer questions.

I wrote this a couple years ago. Since then I've been working on my own CRDT called Diamond Types[1], which uses a lot of these ideas to be bonkers fast. I've built several OT based collaborative editing systems, and diamond types is much faster than any of them - though rust and wasm might be the real MVPs here. I wrote a follow-up to this article last year when I got that working, talking about how some of the optimizations work. That article is here[2].

A fair bit has changed since I wrote that article. Yjs has started a rewrite in rust (called yrs[3]). And Automerge has apparently dramatically improved performance based on some of the ideas I talk about in this article. Oh, and diamond types has been rewritten from the ground up. Its now about 5x faster than it was last year, by completely changing the internal structure. But thats a story for another day.

Unfortunately I still only support collaborative text editing. Adding full JSON support comes soon, after I document some more of the tricks I'm doing. Its really fun work!

Why do I only support collaborative text editing? Because I care about performance, and text CRDT performance is hard because you have so many individual changes. (One for each keystroke!). Making text editing fast means everything is fast. But we've still got to do the work. To make that happen, my plan is to add full JSON editing support to diamond types using shelf[4]. Shelf is a super simple CRDT which fits in 100 lines of javascript.

[1] https://github.com/josephg/diamond-types/

[2] https://josephg.com/blog/crdts-go-brrr/

[3] https://github.com/y-crdt/y-crdt/tree/main/yrs

[4] https://github.com/dglittle/shelf

Yep. I've done something very similar on top of Diamond Types for a little personal wiki. This page[1] is synced between all users who have the page open. Its a remarkably small piece of code, outside of the CRDT library itself (which is in rust via wasm). The way it works is:

- On page load, the server sends the whole CRDT document to the browser, and the server streams changes from that point onwards.

- When a change happens in the browser, it makes that change locally then and sends anything the server doesn't know about upstream.

- Whenever the server finds out about a new change, it re-broadcasts that change to any subscribed browser streams.

I'm using the braid HTTP protocol for changes - but we could easily switch to a SSE or websocket solution. It doesn't really matter.

At the moment I'm just using flat files for storage, but there's nothing stopping you using a database instead, except that its a bit awkward to use efficient CRDT packing techniques in a database.

[1] https://wiki.seph.codes/hn

Code is here, if anyone is interested. The whole thing is a few hundred lines all up: https://github.com/josephg/diamond-types/tree/0cb5d7ecf49364...

With each change we just send the missing operations. Https://wiki.seph.codes/reddit if you want to mess around and see it in action via wasm. The code which runs this wiki is here.

Another way to trace allocations in rust is to inject some code in a global allocator. Then you can use any in-program code you like to print / track / trace allocations. For example, I wrote this code in a library I’m working on so I can track and print out how many total bytes have been allocated, and how many allocation calls have been made.