Trust On First Use
1,785 karma · joined November 14, 2011
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.
We don't want to turn people off with the use of Tor (since it makes connecting more reliable and is quite fast for chat once connected) so I'd love to learn more about the objection.
1. a community member sends you an invite link containing some onion addresses of community members
2. you sync community data and send a CSR to the community owner.
3. We show an "unregistered" message next to your name until the community owner signs your CSR, at which point you're a full member.
We use PKI.js for the certs. For multi-party message-layer encryption with multi-device support we plan on using: https://github.com/local-first-web/auth, which is inspired by Keybase and a Martin Kleppmann paper.
The biggest difference between us and Skype is that Quiet is open source. But yes, open source businesses can rugpull too, as we saw recently with Terraform.
What about our stack makes you worried about the "enough tech savvy people to fork" piece? One decision we've made deliberately is to build on the most widely-used tech, so that maintenance will require less expertise than for a homegrown stack, and so there will be existing communities around the stack that are bigger than the Quiet community. I would love to know more about what problem you envision in building a tech-savvy open source community around our stack. Too boring?
If our business is upselling users to server-backed subscription plans, I think even the threat of a fork goes a long way to keeping us honest, especially since a community fork would not need to run infrastructure. If "Quiet Co." (or whatever we call ourselves) is suddenly no longer the most trusted purveyor of Quiet, we wouldn't have much of a business, which is as it should be in my view.
Re: the politics of providing these tools, I have been preparing, and I have some background in the political side of this from Fight for the Future. It's funny because I am actually quite eager to get to the point where we get to make the social and political case for Quiet to a partly-skeptical world, but first I have to make something that works well on phones! And find users! Ideally we can find some awesome initial users that really tell the story of why Quiet needs to exist.
I'm pretty confident that we can get Quiet to the point where the practical limit of participation in any Quiet channel is storage, relative to the amount of message history that a particular community wants to hang on to for a particular channel.
It wouldn't be crazy difficult to shard storage either. Once we do, a community could store a lot of data by marshaling many nodes with low or uncorrelated downtime. Paying for storage is also an option.
Re: interop, the easiest way to interop would be if Matrix solves all these problems for us before we get anywhere close! Then we can be a P2P Matrix client or just use Matrix :)
But I bet either way it will be possible to make robust transformation layers between different eventually consistent protocols. This is similar to one of the hard problems: interop between multiple versions of a single decentralized application. If we solve that it might generalize if we can bridge the network layers too?
And yes, there is indeed a really long list of hard problems to solve. I really really hope one of us, or one of the other similarly motivated projects, is able to solve them all and deliver the whole package!!!
Push to talk was a thing in old-school mobile telephony. It's basically audio messages but they play as soon as you receive them (or stream) so it feels more like a conversation.
It seemed important to get unique usernames within a community because users expect that from apps like Slack and Discord.
Network layer privacy is even more layered in this way. A burner HN account is very anonymous for a wide range of threat models. But if you're a terrorist or spy, NSA and GCHQ will see to it that they break anything you use. Users can learn about the properties of different tools and make informed decisions. Nobody should do something they would not otherwise do just because they believe they are protected by Tor. That is a bad idea. But if someone needs to do something sensitive and wants to lower their risk profile, Tor will likely help and it's fairly low-cost to use it.
Another way to look at it is: any naively implemented p2p communication tool will reveal the IP address of all your conversation partners by default. Tor is a big improvement over that, and comes with other benefits, like NAT traversal and peer discovery.
(Quiet founder here) Great question! If you're already happy running your own self-hosted Zulip/Rocket/Mattermost/Matrix and you have no problems with maintenance or downtime, Quiet is just a cool demo and probably not useful!
If you cannot run a server (a minority on HN but a majority of the world) or you do not want to (maybe a slim majority on HN?) and you need a team chat with nice privacy properties, Quiet is being built for you!
The thing that frustrates me about free and open source software that requires servers is: most people don't have servers! And the prevalent model for using others' servers involves a terrible power / dependence relationship. One thing that drives me to build Quiet is that I want to see a world where free software comes "batteries included" with all of its promised freedoms and advantages, for the vast majority who do not have servers.
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 p2p text editing I would also look at the Braid project (braid.org) 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
Aw thanks. That is what we're going for. One that makes sure others will always be able to give their gifts to humanity.
> I'm glad to see you are thoughtful about many protocols here. Will you be adding i2pd support?
There is no current plan to. I'd be super curious to see how well it works, but we have so many bigger fish to fry! My guess is that adding i2p support on desktop would be straightforward and that on mobile it would be costly. Would desktop-only i2p support be useful to you?
> Could you make explicit for us what parts of this tool are the least decentralized?
Our source control, update server, and CI! It would be awesome to have a p2p github alternative that could ship builds over BitTorrent or IPFS. Someday! :)
Beyond that, there are some pieces of Tor that are less decentralized (Guard nodes, e.g.) but everything else is just client code running over Tor talking to other clients.
> Do you need computational donations to the network?
Right now, the best way to donate to the Quiet network is to run a Tor relay. Beyond participating in Tor, Quiet does not allow you to help any network you're not a member of!
If you have access to a large number of machines, rigorous performance testing with hundreds of nodes could possibly be helpful? In the past we've used Fargate for this, but this is expensive so it would be nice to have something running in an ongoing way. Also, manual and automated testing on many diverse Android devices; that would be helpful!
> How can I assist?
The thing we need most are real communities of people who desperately want to switch away from Slack, Discord, or Signal but don't have a satisfactory solution. Specifically, we want to learn about their use cases and tailor Quiet to their needs as much as possible. Know anyone?
> Do you intend to provide users complete control over private/public keys within the interface?
Yes. Right now user keys are stored on their machines and nowhere else, but you have to just copy a directory to move them or back them up. Soon we'll let people recover accounts from their linked devices (e.g. from your computer if your phone is lost) and we may have some social recovery solution within communities for DMs, though that might not be feasible. We'll also do the crypto wallet thing of encouraging people to write down passphrases, but most users won't do that.
> Will you be providing significant command-line access to the tooling?
The backend is its own Node module, but we don't have a good CLI for it yet and it's not a current priority: https://github.com/TryQuiet/quiet/tree/develop/packages/back...
> How far have you attempted to scale this up?
We've run tests with 200-300 nodes on Amazon Fargate, and our frontend was the bottleneck, not the p2p layer. Libp2p currently handles 800,000 nodes on the Ethereum beacon chain. Phones will need to be given some more limited view of the network for large communities to remain performant, and we will need to add retention limits for messages and images otherwise drive space will be the bottleneck, but there is no reason why we cannot handle very large communities.
> Will you be working toward collaborative text environments like Etherpad Latency seems too high for that, right?
For text documents, latency isn't the issue, but CRDT performance is because every character is a new CRDT transaction. We would love to pursue this if our users ask for it. So far there isn't a strong signal that users need it. Many people I talk to use documents to prepare things for intended eventual publication, while they use messaging for in-progress thoughts, so docs are not as sensitive as messages. It's like, docs are an organization's mouth and messaging is an organization's brain. You care more about the privacy of your brain. But technically this would be a fun challenge and I'm sure we could build something great. There are other CRDTs we could use.
> Do you intend to enable the synchronization of larger sets of files, something like mutable torrents?
This would probably be straightforward. What's your use case?
That said, they have to solve more problems than just the problems solved by Pinecone. (Like onboarding and identity.) And over the past few years my impression has been that the Matrix team is focused on the federated use case, because that's where their users are. It seems hard for them to pay attention to both.
My guess is that P2P Matrix will land as an awesome reliability feature for uninterrupted messaging when a server goes down or when the Internet goes out, but that it will take longer for them to tackle problems specific to P2P that don't graft on easily to federated Matrix.