[HN Gopher] Quiet - Encrypted P2P team chat with no servers, jus...
___________________________________________________________________
Quiet - Encrypted P2P team chat with no servers, just Tor
Author : sschueller
Score : 427 points
Date : 2023-09-12 06:29 UTC (16 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jstanley wrote:
| This sounds like a much more polished alternative to Ricochet:
| https://github.com/ricochet-im/ricochet
| lordofgibbons wrote:
| As far as I know, there is no way to run IPFS over Tor.
|
| It also says it relies on OrbitDB, which runs on the IPFS, but
| IPFS has to run on clearnet, and when the user accesses a
| content, then an observer can see what content they fetched
| because their node will broadcast it. I feel like I'm missing a
| piece here..
|
| The Readme also says Tor2web is used to share files. I'm not
| familiar with this, but wouldn't that require the user to trust
| the entities who run these servers to not snoop on their traffic
| before it enters the Tor network?
| jeroenhd wrote:
| Tor can tunnel any protocol, including IPFS. The normal IPFS
| network and the Tor IPFS network can't really interface without
| nodes bridging the gap by speaking both protocols. There are a
| few PoCs out there for adding Tor support to IPFS.
|
| Tor2web makes the claims a little suspicious, but technically
| speaking the system _could_ work.
|
| Now that Veilid is out (https://veilid.com/), that seems like a
| much better base to build a messenger on top of, but it
| probably doesn't support the IPFS features this thing requires.
| Maybe a v2 can use it to get the privacy features it needs.
| AceLewis wrote:
| Tor works on top of TCP so it can't tunnel UDP traffic. Lots
| of P2P things (like torrents) support both UDP and TCP, some
| only UDP. If you try to torrent and only have TCP you won't
| be able to connect to other peers using UDP.
| holmesworcester wrote:
| (Quiet founder here)
|
| IPFS can actually run quite well over Tor, and you don't
| have to use IPFS on a big global network for it to be
| useful.
|
| We've modified the libp2p WebSocket transport to connect
| exclusively over Tor to Tor onion services, and we give
| every Quiet community (like a Discord "server" or Slack
| workspace) their own IPFS network. Since Tor v3 onion
| addresses are unguessable, this creates a nice outer
| security boundary around each community.
|
| As others in the thread have pointed out, the disadvantage
| of not using a global IPFS network with "pinning services"
| etc. is that if no one else in your specific community is
| online, asynchronous message delivery will be disrupted.
| That said, I believe the privacy benefits are well-worth
| it.
|
| IPFS is also _much_ more performant when running on
| networks of a few hundred or thousand users, as opposed to
| the big global network, so that 's another nice thing about
| the approach we've taken, in addition to the privacy
| benefits.
| lordofgibbons wrote:
| How does the IPFS DHT, which is built on UDP, work on Tor? As
| far as I know, Tor doesn't support UDP, and DHTs are
| massively inefficient over TCP.
| thetoon wrote:
| Maybe it's using IPFS to share encrypted pieces of data, and
| only shares encryption keys through Tor?
| yankput wrote:
| I would ask on github through issues if I were you
| boredumb wrote:
| As someone using matrix currently: Is there a reason i'd switch
| to something like this for my business use or is their really
| only legit use cases around journalists/activists?
| TheNorthman wrote:
| The advantage of tor over just E2EE is that it hides the
| sources of traffic and not only the traffic itself.
|
| So it really depends on if your threat model can handle others
| knowing that you're using Matrix. It most likely can.
| kkfx wrote:
| Mh, XMPP is well known, open, _far lighter_ than IPFS... Why the
| hell I 'd want a MONSTER software just to chat knowing that "real
| security" of such giants is far theoretical since they are so big
| that their knowability is limited for anyone and attack surface
| is enormous?
|
| Dear devs I know some tech are trendy, but please focus on good
| tech, not monsters.
|
| For socials we have Usenet, today antispam can handle the task,
| and the rest while from another era works well enough. For chat
| we have IRC and XMPP, with the latter far more modern,
| featuresful and still simple enough, we have mails. Sharing files
| is still complex but syncthing works for mere exchange, ZeroNet
| is good enough for simple distributed web.
|
| We have enough crappy monsters from the commercial big tech world
| to add others.
| jstanley wrote:
| In what way is ipfs a monster? It is a single go binary that
| does a tiny number of jobs.
| jeroenhd wrote:
| IPFS is a resource hog. Not sure if it's just the
| implementation or if it's because of architectural
| limitations, but it gobbles up CPU and RAM much more than
| you'd expect it to. I shut down my self-hosted IPFS server
| because it kept pegging a CPU core doing what seemed like
| nothing (no new pins, barely any network traffic, just
| sitting there).
| holmesworcester wrote:
| (Quiet founder here) Yes, IPFS is a resource hog when
| running on the global IPFS network, but Quiet never touches
| that network, and this improves performance a _lot_.
|
| I can run Quiet in the background all day on my Pixel 6 and
| we haven't even started optimizing for battery life yet.
| Grimburger wrote:
| Client side compute for other random people is probably what
| GP is talking about here.
| jstanley wrote:
| IPFS doesn't do that, are you thinking of something else?
| Grimburger wrote:
| https://discuss.ipfs.tech/t/high-bandwidth-and-cpu-usage-
| fro...
| kkfx wrote:
| Did you try to look at IPFS codebase size?
| jstanley wrote:
| ~/kubo$ find . -name \*.go | xargs wc -l | tail -1
| 59629 total
|
| Doesn't seem that big?
| kkfx wrote:
| YES! Compared to a simple IRC server+client or XMPP
| definitively.
| bogwog wrote:
| My users complain all the time about the LoC of my
| codebase
| jstanley wrote:
| Well irssi is an IRC client and is bigger than that:
| ~/irssi$ find . -name \*.[ch] | xargs wc -l | tail -1
| 88551 total
|
| https://github.com/irssi/irssi
|
| Obviously ipfs doesn't have the chat UI, ipfs is just a
| protocol layer.
|
| But it is a more complicated protocol than IRC, so you'd
| expect it to be larger. I don't think it's large out of
| proportion, certainly not large enough to call it a
| "MONSTER software".
| mrusme wrote:
| I'd like to point out that you probably cloned
| https://github.com/ipfs/kubo there, which is only one
| part of what accounts for the "IPFS codebase". If you
| want to find out the actual LoC, I'm afraid you will need
| to dig through
| https://github.com/ipfs/kubo/blob/master/go.mod and pick
| everything that's github.com/ipfs/*, github.com/libp2p/*
| and github.com/ipld/*.
| jstanley wrote:
| Fair point!
| komali2 wrote:
| Well, XMPP is nice, but ZeroNet also seems like a monster.
| thfuran wrote:
| >For socials we have Usenet, [...] For chat we have IRC
|
| You can't be serious. Should we abandon displayport because we
| have vga?
| kkfx wrote:
| it's not the same: IRC or XMPP are _very small_ piece of sw
| compared to IPFS alone. While for messaging do essentially
| the same: why using a many hundred of megabyte app when a
| 10Mb one can do the same?
| holmesworcester wrote:
| (Quiet founder here)
|
| We love XMPP and IRC, but both IRC and XMPP require
| servers, and most people don't have a server or even a
| friend who has a server, so they depend on Google,
| Facebook, etc.
|
| There may be work in the XMPP space on a pure p2p XMPP, but
| based on my conversations with folks in the (awesome) XMPP
| scene last year at FOSDEM, it was pretty experimental and
| there were major problems they hadn't tackled yet, like
| identity.
|
| Quiet is an effort to make a chat app that works well out
| of the box without depending on a server (or a company.)
| This feels new, different, and helpful to the world right
| now! And achieving this goal feels worth loading a few MB
| of dependencies or even (gasp! wince!) Electron :)
| kkfx wrote:
| Thanks for sharing them :-)
|
| > most people don't have a server or even a friend who
| has a server,
|
| That's wrong from my point of view. In the past, in the
| dialup era that's normal, but we are in the fiber optic
| broadband era, at least in vast part of the world who are
| essentially the parts where IT is developed and used, so
| it's wrong not to have an IPv6 static global per device,
| it's wrong not having a domain name per human being, at
| least per Netizen.
|
| Correcting this is anyway needed because even with modern
| connections distributed solutions have too much overhead,
| too little performances to be generally used. Having a
| homeserver, a direct connection with own devices, from
| cars to "smart" water heater should be normal for those
| who want it, normal without intermediaries but still with
| server, we need to know our infra.
|
| Building giant tools to circumvent actual state of things
| is technically fascinating, give end user a friendly UI
| is remarkable but it does not really solve the background
| problem: giants services will be much more performant. On
| contrary no giant can offer something more effective than
| a direct connected services for any user, from a single
| device with data and logic and UI on it, to LAN to
| generic P2P connection without extra overhead. As a small
| example no VoIP services can be faster in my LAN than my
| local softphones/deskphones talking each others. No GMail
| alike service can search faster than my local notmuch-
| emacs on local maildirs. No file sharing services to
| exchange a file can be faster than a direct connection
| between someone else and me, at the maximum extreme they
| can be nearly equivalent.
|
| At least, that's my vision: no chance to win competing
| with big & powerful on such tech, some chances pushing a
| local first, wide open connection between peers for the
| rest because users are needed, but nerd, people who know
| what they use is even more needed to start, just
| understanding IPFS from it's code and "docs" is
| challenging, understanding IRC is far simpler.
| MattJ100 wrote:
| I remember chatting with you at FOSDEM (Snikket dev
| here). Congratulations on the launch!
|
| Generally I agree that the goals of Quiet are
| sufficiently different to the way XMPP is used/deployed
| today that your entirely different stack is warranted.
| While people do use XMPP with Tor today, and I'd like to
| add native Tor support to Snikket at some point, I don't
| envision that ever working the way Quiet does.
|
| Nevertheless, an XMPP<->Quiet bridge would be a fun
| project for someone, some day :)
| awestroke wrote:
| Seems like you can add people to your community but not remove
| them.
| verandaguy wrote:
| EDIT: this comment's mostly moot as an argument but I'm keeping
| it around for discussion. The founder of Quiet replied here[0].
|
| This being on Tor gives me mixed feelings.
|
| Tor's a volunteer run, _fairly_ resource-heavy privacy tool
| designed to protect the most vulnerable internet users out there
| -- people facing state censorship on the level of corporal
| punishment being used, for example. While the Tor network has
| more capacity these days than it used to, and while having a good
| toolchain for Tor 's intended user base matters, that's rarely
| the intended user base of apps like this.
|
| When something like Quiet comes along, even with its targeting of
| users in open societies, it would benefit both technically and
| ethically from using non-Tor networks: HTTPS is safer than ever,
| and if you use ECH, DNS-over-HTTPS, and have reasonable cipher
| requirements for TLS, you can achieve an excellent level of
| privacy.
|
| For when open society groups need to talk to people at risk of
| harm, having a Tor bridge or other such mode would be a good way
| to approach that. It also makes implementing video and audio much
| easier technically, and it decouples the "casual user" code base
| from the "sensitive user" code base; while that means you might
| have less shared code, it also means you can focus on security
| through simplicity (by way of fewer or less-complex features) for
| the sensitive users. [0]
| https://news.ycombinator.com/item?id=37480552
| orbital-decay wrote:
| Increased adoption also drives the volunteer amount increase.
| Every non-shady use of Tor is welcome, as it improves the
| network reputation, anonymity, and protects the use case it was
| created for.
|
| The more immediate issue for Tor is the vulnerability to
| fingerprinting if the use of Tor Browser falls below the
| comfortable levels.
| holmesworcester wrote:
| (Quiet founder here)
|
| I've been a bit breathlessly replying to comments and am now
| late for a weekly team meeting, but I just wanted to say that
| we're friends with the Tor Project, they like us and support
| apps like Quiet (and Briar, Cwtch, etc.) existing, and we're
| also part of a small circle of Tor fans who funded Tor to hire
| two full-time engineers to focus on onion services reliability
| after the DDoS attack last year, so we're donors to the project
| too.
|
| Also, it's likely that distant future versions of Quiet (where
| we reach a large audience) will use Tor as just one way to
| connect. Gotta go but will respond more thoughtfully soon!
| bauruine wrote:
| Adding to this as a relay operator, while I can't speak for
| the Tor Project or other operators, I think this is a
| perfectly valid use case for Tor and I happily provide
| ressources for it.
| holmesworcester wrote:
| Aw thanks!
| verandaguy wrote:
| I appreciate you taking the time to reply, and thanks for
| being involved with Tor on this! If they're fine with it, I
| trust you're good in terms of resource usage.
| holmesworcester wrote:
| We are very aware that Tor has created a public good, very
| grateful for it, and we will not abuse it.
|
| In a world where Quiet is a significant portion of Tor's
| ~2-3 million users (good problem to have!) we'll be in a
| good place to add other transports. Someday Quiet could
| even encourage users to run Snowflake bridges! (Though we
| have a lot of work to do before that would be meaningful at
| all!)
|
| Also, thanks for saying that and for updating the comment
| in response to more information! People aren't always so
| gracious in online forums and I'm sincerely grateful.
| KennyBlanken wrote:
| > HTTPS is safer than ever, and if you use ECH, DNS-over-HTTPS,
| and have reasonable cipher requirements for TLS, you can
| achieve an excellent level of privacy.
|
| Is ESNI or ECH actually in significant use?
| verandaguy wrote:
| Given that it's still fairly new (just coming out of draft in
| the coming months), no, it's not, but it is _in_ use, and it
| can be deployed by server operators and client devs in its
| draft state.
|
| With low adoption comes the risk of flagging by bad actors on
| the network, but hopefully that goes away quickly after ECH
| comes out of draft.
|
| The silver lining of having so much of the internet
| controlled by massive, monolithic actors like Cloudflare and
| Google is that when they flip the switch on ECH, it'll be
| widely in use within weeks or days, not months or years; and
| while I don't keep up with Google's involvement, it does seem
| like Cloudflare's been active on the ECH front with the IETF.
| [deleted]
| anon____ wrote:
| On the other hand, if projects like this, as a side effect,
| increase the number of relays, and normalize using Tor, it's a
| win for everyone. Quiet should pay for a few servers to be used
| as relays and exit nodes, and also encourage users to do so, or
| to donate to that.
| chx wrote:
| > normalize using Tor,
|
| Yeah that will not happen.
|
| https://news.ycombinator.com/item?id=36906900
| hiatus wrote:
| How do exit nodes factor in? This seems to operate like
| hidden services thus no exit nodes needed.
| holmesworcester wrote:
| (Quiet dev here.) Correct. Quiet traffic does not use Tor
| exit nodes, though we might use them someday, e.g. for
| fetching preview metadata when you post a link.
| chx wrote:
| This was a comment about the general normalization of
| Tor.
| hiatus wrote:
| A broadly used application that requires tor for everyday
| use would be beneficial for the general normalization of
| tor. How would many people using quiet be anything but a
| step in the direction of general normalization of tor?
| anon____ wrote:
| What do you mean by that?
| madamelic wrote:
| You don't get to choose what flows through your exit
| node.
|
| It could be a Chinese dissident, it could be someone
| accessing a child porn forum.
|
| When authorities go to track down the IP that sent
| requests to another, your IP will be the one listed on
| that request with no ability to trace back what IP
| actually sent the request so it will be difficult to not
| pin you for whatever was accessed.
| anon____ wrote:
| This is true and already reality, no need for
| hypotheticals. There are exit nodes serving child porn
| right now, yet, the operators are not prosecuted.
|
| The child porn traffickers and other problematic users
| are all on Tor already. With the growing number of users
| their proportion will only decline.
| chx wrote:
| > With the growing number of users their proportion will
| only decline.
|
| [citation needed]
| anon____ wrote:
| My only assumption that would need citation (that I
| cannot give, I admit) is that currently the proportion of
| shady users is much higher on Tor than on the general
| Internet. From here, it's pure and simple logic: as more
| users transition to Tor (asymptotically all of them),
| this proportion can only decrease.
| chx wrote:
| 1. there's no clear indication whether the Tor userbase
| grows. Indeed, I would suspect the constant mobile is a
| hindrance 2. There's no clear indication in which
| direction the online CP people grow. They can be more or
| less over time. I am unaware of any studies because it's
| obviously extremely hard to measure.
| LinuxBender wrote:
| _You don 't get to choose what flows through your exit
| node._
|
| This is why it is important to bookmark ExoneraTor [1] so
| that one can prove the IP in question is/was a Tor exit
| node accepting that it would still be a PITA to deal with
| boots-on-neck and legal fallout.
|
| That said one could block some of the _known_ illegal
| sites _via DNS and IP null routing_ on the exit node at
| the risk of the Tor network flagging it as a malicious
| exit node.
|
| [1] - https://support.torproject.org/glossary/exonerator/
| holmesworcester wrote:
| (Quiet founder here) We already support Tor financially and
| will probably also run relays someday!
|
| Quiet is a founding member of Tor's Onion Services Resource
| Coalition, which started in response to last year's DDoS
| against the Tor network, which affected onion service
| connection times. Alongside a small circle of other affected
| products we helped Tor raise enough to hire ~2 full-time
| engineers to work on onion service reliability, which had
| been a bit underfunded because onion services only represent
| a small share of Tor's existing usage.
|
| See: https://blog.torproject.org/tor-network-ddos-attack/
| anon____ wrote:
| Thanks for addressing this, this is great to hear!
| rakoo wrote:
| > [Tor is] designed to protect the most vulnerable internet
| users out there -- people facing state censorship on the level
| of corporal punishment being used, for example
|
| While this is the reason Tor was created, I don't believe it's
| good to segregate usage based on whether we actually need that
| level of privacy or not. If anything, using tor when no one
| else uses it _may decrease_ privacy, because you 're more
| easily targetable. If everyone uses it all the time, it's not
| clear anymore whether you're using it because you actively try
| to protect yourself or it's just there. Just like SSL was
| created at a time when businesses started to get interested in
| the web, now TLS is used for everything and can't be used to
| target specific uses.
|
| Tor is like vaccines and masks: it works better if everyone
| uses them
| wizzwizz4 wrote:
| _If you are running an exit node,_ yes. However, if the
| general public takes up this advice, connections will time
| out before the whistleblower has finished uploading the 15GiB
| .zip to the dead drop.
| thinkmassive wrote:
| > it would benefit both technically and ethically from using
| non-Tor networks
|
| Obviously the performance of tor is reduced when traffic
| increases, but performance isn't the goal, privacy is.
| Increasing the traffic of "normal" use cases (as opposed to
| those targeted by state-level opposition) improves privacy for
| the entire network.
|
| I agree that using tor for all your video conferencing and
| streaming needs is probably irresponsible, possibly unethical,
| but the performance is likely to be so poor that it's not a
| good use case anyway.
|
| Using tor for everyday text chat (by real humans) is unlikely
| to have a negative performance impact, and it does provide more
| noise for attackers to sift through, so it could arguably
| improve privacy for those who need it most.
| verandaguy wrote:
| >performance isn't the goal, privacy is
|
| I agree, but if performance gets bad enough, people will look
| elsewhere and to possibly less-private solutions. It's
| parallel to the whole idea of a tradeoff between convenience
| and security that I've had to deal with for a big part of my
| career (and personal anecdotes aside, why adoption for tools
| like PGP never picked up, at least in part).
|
| Anyway, my original comment's mostly moot as an argument
| (though I'll keep it around for discussion's sake) -- the
| founder replied and it sounds like they're working with Tor
| to make sure the network stays healthy, which is all I really
| care about.
| thinkmassive wrote:
| > adoption for tools like PGP never picked up
|
| nit: Every competent developer I know uses PGP on a daily
| basis, for signing and validating commits. The responsible
| ones also use it to validate security-critical software is
| coming from the expected source. I do agree though, that
| the original use case of encrypted email is largely dead.
| verandaguy wrote:
| Good point, though in Git's case there's the benefit of:
| - Users are at least somewhat technically minded - The
| ecosystem built around Git generally has good automated
| tooling for verifying signed commits (Gitlab and Github
| in particular surface that information pretty well)
|
| With security-critical software, specialists take on the
| burden of knowing how to use it as part of being in that
| field.
|
| Email sadly has none of those, and the one client I've
| used with a "normal"-user-friendly GPG interface (Nylas
| N1) is now a subscription service with limited adoption.
| Enigmail was better than the CLI, but still not super
| intuitive for the average person.
| mlinsey wrote:
| if Quiet doesn't catch on to provide that noise, would it be
| beneficial to flood Tor with LLM-generated conversatinos?
| We're really good at "cheaply generate near-infinite
| quantities of human-looking text" these days...
| mulmen wrote:
| Presumably the content of the message is irrelevant to Tor.
| If the humanness of the content matters then the game is
| over anyway because that means it's being read by a third
| party.
|
| What matters for Tor is plausible looking _traffic_ and
| uninteresting people doing uninteresting things with it.
| Then you can't use traffic analysis to identify Tor users
| as points of interest.
|
| If everyone on Tor is evading an oppressive government then
| oppressive governments can just use Tor to identify the
| people evading them.
| snvzz wrote:
| How does it compare to the more mature Tox[0]?
|
| From a glance, it just looks heavier, more complicated, more
| moving pieces and opportunities for bugs.
|
| 0. https://tox.chat/
| KirillPanov wrote:
| Tox is the wireguard of this space.
| holmesworcester wrote:
| I've got to do a deeper dive on Tox and see what we can learn
| from it, and add an entry to the "comparisons" section in our
| FAQ!
|
| I've been meaning to write one for BitTorrent Bleep too,
| which is also interesting prior art.
|
| https://github.com/TryQuiet/quiet/wiki/Quiet-FAQ#how-
| quiet-c...
| factormeta wrote:
| Hmm don't see it yet on the FAQ yet.
| notpushkin wrote:
| And before that there was TorChat [1] and another similar
| program I can't remember. I think both had some UX problems,
| but more importantly, they are generic chat networks like
| WhatsApp or Telegram, while this seems to be targeted
| specifically at Slack users (and the whole PKI architecture
| they rolled sounds like a nice fit for that).
|
| [1]: https://en.wikipedia.org/wiki/TorChat
| holmesworcester wrote:
| (Quiet founder here) Prior work like TorChat and Ricochet was
| actually a huge inspiration for Quiet. We build on their
| insight that if you use Tor onion services as your addresses
| in a peer-to-peer network, a lot of things get simpler.
|
| Where Quiet goes farther is that Richochet (and I believe
| TorChat) offered 1:1 synchronous message delivery where each
| user sends directly to another user's onion address. Group
| chats were not possible, and messages were delivered only
| when both users were online. In Quiet, having a gossip
| network (libp2p) and a CRDT (OrbitDB) lets us do group chats
| with the "eventual consistency" property that messages sent
| while you were offline can be synced from other peers when
| you return. This also allows for asynchronous message
| delivery of DMs in most cases: you can gossip your
| (encrypted) DMs to all peers, and as long as there is a
| continuity of syncing between peers, the recipient will be
| able to retrieve them even if you are no longer online. So
| yes, there are some more moving parts, but they let Quiet be
| a lot more like Slack, Discord, Signal, Messenger, and most
| modern messaging apps than TorChat or Ricochet were, which
| means Quiet can be more functional and familiar to new users
| looking for alternatives.
|
| I remember Tox from back in the day, but to my chagrin I have
| not assessed it since I started work on Quiet (I try to keep
| up on these things but there is so much prior work that
| didn't catch on for one reason or another!)
|
| At a glance, it looks like Tox supports groups, which goes
| beyond Ricochet.
|
| The most obvious single difference I see between Tox and
| Quiet right now is that Quiet is available for iOS
| (Testflight, for now) and Tox is not. iOS support has been a
| brutal slog (and the slog is not over) but it is a deal-
| breaker feature for every real-world team or community we
| have been able to talk to, so we are committed to making it
| work well.
| hanniabu wrote:
| I'm surprised there's no direct messages yet, I would think
| that'd be a trivial step from group chat
| badrabbit wrote:
| Probably like Matrix where a DM is a chatroom but only one
| person invited so far.
| holmesworcester wrote:
| (Quiet founder here) The non-trivial thing about DMs is
| multiple device support, so that when someone sends you an
| encrypted DM you will receive it on any of your devices.
|
| We've also been prioritizing basic functionality on Android
| and iOS over many common-sense features like DMs because
| there is a lot of risk there. All users we talk to need
| reliable mobile support, so we want to ensure we have that
| locked down to a sufficient degree before adding a bunch of
| features (to be a bit melodramatic, we want to make sure we
| aren't polishing deckchairs on a Titanic!)
|
| But we have a concrete plan for encrypted group messaging
| with multiple device support and removal. We plan on using
| this library: https://github.com/local-first-web/auth
|
| It is very bleeding edge but is based on academic work by
| Martin Kleppmann and built in conjunction with the folks at
| Ink & Switch, so it's an earnest attempt at a solution. We'd
| love to use MLS but it's too complex and narrowly focused, I
| think, to be a good fit at this stage.
| mrusme wrote:
| While I do like the idea behind a P2P E2EE chat, I believe that
| unless you're willing to invest heavily into OrbitDB and IPFS,
| this project will stay niche at best.
|
| The performance issues that come along with running OrbitDB/IPFS
| on a machine, let alone a mobile device, are still significant
| unfortunately. Adding Electron on top of what is already a heavy-
| weight application is probably going to make people's devices go
| brrrrr all the time. Not only that, but I would argue that for
| instant communication this stack might not be the best idea in
| terms of performance in first place.
|
| Besides, the way IPFS has been (and still keeps) changing their
| dozens of libraries doesn't make development particularly smooth
| either. OrbitDB is always behind the latest IPFS version due to
| all these changes that are being introduced. Hence unless you're
| planning to allocate developer time on these two things as well,
| my guess is that you probably won't have too much fun with your
| back-end.
|
| The integration with Tor is another thing that will likely be a
| time drain for developers, as other people here already pointed
| out, and that will lead to even more performance issues down the
| line.
|
| Don't get me wrong, I really like the idea behind this project.
| However, I feel like the aspirations are unrealisticly high and
| the actual outcome might be realtively frustrating for the
| average end-user. Having that said, I would love my gut feeling
| to be proven wrong!
|
| Disclaimer: I'm the developer of Superhighway84
| (https://en.wikipedia.org/wiki/InterPlanetary_File_System#App...,
| https://github.com/mrusme/superhighway84), a USENET-inspired,
| uncensorable, decentralized internet discussion system running on
| IPFS & OrbitDB.
| _-_-__-_-_- wrote:
| Your website is awesome. I read it all the time to get
| inspiration for my own projects. Please keep positing builds
| and making awesome projects.
| chasingtheflow wrote:
| Which site?
| holmesworcester wrote:
| Thank you!!!
| jadbox wrote:
| Isn't orbitdb mostly abandoned now by the core team? I looked
| into it a few months ago and read that it's in a maintenance
| state.
| holmesworcester wrote:
| OrbitDB is not well-funded, but there's fresh work happening
| recently by some dedicated volunteers:
| https://github.com/orbitdb/orbitdb/commits/main
| holmesworcester wrote:
| (Quiet founder here)
|
| All of these things are true and it's clear you know the
| problem space well! We avoid the primary "go brrrrr"
| performance issue with IPFS by using small private IPFS
| networks and never touching the noisy, CPU-intensive global
| network.
|
| You didn't even mention the biggest time drain, which is
| getting everything to work well on Android and iOS! This is on
| track to _dwarf_ all other time drains by 10x or more.
|
| However, the amazing thing is, as full-of-warts as the stack
| we've chosen is, it isn't a clearly worse choice than the
| alternatives, from GUN, to Hypercore, to the Automerge space,
| to Braid, to Holochain, P2Ppanda, and so on. All the other
| attempts to build a general purpose stack have a few things
| they do well and a bunch of things they don't do well, or at
| all, or they have similar questionable longevity to something
| like OrbitDB.
|
| But if you believe what we both believe (i.e. that users
| shouldn't have to depend on someone else's server or run their
| own just to gather online) what is to be done? It seems like
| you decided to roll up your sleeves and try. Maybe the
| necessary ingredient is PG's "Schlep Blindness" [1] where you
| have to be pretty naive or masochistic to get started but if
| you keep pushing you can make something really new and
| valuable.
|
| I think the reason why the field is in this place is simply
| that a general purpose p2p stack for user-facing apps needs to
| do the impossible: it needs to build complex solutions to an
| actually very long list of heterogeneous problems, _without
| clear knowledge of what those problems are and what form they
| take in production,_ because there aren 't any successful,
| desktop + mobile peer-to-peer apps yet to provide that reality-
| tested information, unless you count WebRTC video calls, which
| only covers a small piece of the picture.
|
| So we just have to push through. And it's fun! Also, please do
| DM or email me! I'd love to compare notes more deeply than
| would be possible here (same offer goes for others who are
| interested in these questions!): h [at] quiet.chat
|
| 1. http://www.paulgraham.com/schlep.html
| motohagiography wrote:
| The hard part about making a new P2P protocol is that first
| you have to invent the internet.
| holmesworcester wrote:
| this statement works on a number of levels!
| horsawlarway wrote:
| > i.e. that users shouldn't have to depend on someone else's
| server or run their own just to gather online
|
| I don't understand this. Can you elaborate exactly what you
| mean?
|
| Because to me... you're now just depending on a _whole_ bunch
| of other people 's machines indirectly, and directly on the
| community owner's machine which is generating the certs.
|
| It feels like a lot of complexity for something that could
| just be a small chat server running on the community owner's
| server (which they will need anyways - unless I'm
| misunderstanding, which is entirely possible).
|
| ---
|
| So since I'm probably missing something - can I get the
| elevator pitch?
|
| Assume I'm your target market (I want private messaging that
| I control).
|
| I would likely be a "community owner" as described in your
| article.
|
| I am already running a self-hosted solution (ex:
| Zulip/Rocket/Mattermost).
|
| What makes this a compelling offering to me?
| gabereiser wrote:
| You aren't missing anything. The restriction to community
| fences ensures that each community will have to host the
| community. There's no free lunch. Now, someone in that
| community can be more generous with compute than others.
| Using Tor to try to be anonymous isn't going to work either
| as Tor has been broken.
| Renaud wrote:
| > Tor has been broken
|
| I think you have to clarify what you mean by that.
| Citation needed.
| gabereiser wrote:
| Sure thing. Let me know if you need more. Government
| agencies have been watching for years. Also keep in mind
| that no one has more admin access to network
| infrastructure than government agencies do such that the
| NSA can monitor any computer on the internet.
|
| https://arstechnica.com/tech-policy/2015/01/did-feds-
| mount-a...
|
| https://www.documentcloud.org/documents/2719591-Farrell-
| Weds...
|
| https://mice.cs.columbia.edu/getTechreport.php?techreport
| ID=...
|
| https://www.vice.com/en/article/4x3qnj/how-the-nsa-or-
| anyone...
|
| https://www.techtimes.com/articles/200592/20170307/fbi-
| drops...
| holmesworcester wrote:
| I think it's helpful to have a more layered perspective
| here. Privacy tools never provide absolute protection in
| the real world, because the attacker could always have
| some capability the user doesn't know about.
|
| 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.
| gabereiser wrote:
| Yup. There's no 100% privacy guarantee on a network,
| period. Sorry kids.
| upofadown wrote:
| The first reference is to an attack from 2015 that was
| fixed. So wording is important here. What is meant is
| that TOR has been broken in the past.
| holmesworcester wrote:
| > I am already running a self-hosted solution (ex:
| Zulip/Rocket/Mattermost). What makes this a compelling
| offering to me?
|
| (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.
| mrusme wrote:
| I appreciate the reply and I understand where you're coming
| from. Looking at when you released your first few versions of
| this project, I understand that the options you had at that
| time probably weren't as plentyful or mature as they might be
| today.
|
| > However, the amazing thing is, as full-of-warts as the
| stack we've chosen is, it isn't a clearly worse choice than
| the alternatives, from GUN, to Hypercore, to the Automerge
| space, to Braid, to Holochain, P2Ppanda, and so on.
|
| I think far more interesting these days would be projects
| like Veilid, Hyphanet's Locutus and ultimately Nostr -- even
| though not truly P2P in that sense -- which already happens
| to have a first try going with nostrchat.io. 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.
|
| > It seems like you decided to roll up your sleeves and try.
|
| Ultimately IPFS was designed as a file store, which to me was
| the main reason to use it for Superhighway84. I intended to
| implement USENET-like file attachments and (go-)OrbitDB was
| merely an easier way to deal with the messages posted into
| the groups. However, if instant communication would be my
| main focus, I would rather try more lightweight frameworks
| (see above), especially if mobile devices should come into
| play eventually. Superhighway84 was never intended to leave
| the beautiful space that is the command line and hence niche-
| by-design. :-)
|
| Again, I will definitely keep an eye on Quiet, to see how it
| ultimately evolves on top of IPFS. 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.
| dvasdekis wrote:
| Could I ask, with these p2p/federated projects (and thank
| you mrusme for helping me to get superhighway84 running!
| dope personal homepage, big fan of yours) why doesn't
| anyone use Usenet itself as resilient backup storage?
|
| The Usenet network itself is always online and highly
| resilient - most providers offer ~5000 days of binary
| retention, and endless retention on text - and great
| bandwidth to boot. If a user doesn't have Usenet, or the
| Usenet isn't at the 'current' timestamp, that's where the
| Tor/P2P layer could kick in. You would only need a single
| server (with a private key, trusting the public key in the
| main executable) that continuously archives new posts to
| Usenet to make it work.
| holmesworcester wrote:
| > 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 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
| up2isomorphism wrote:
| libxx.so in a software distribution? Does not look right.
| Tachyooon wrote:
| Does anyone feel like trying this out with some folks from here?
| [deleted]
| GauntletWizard wrote:
| Your selling points are the opposite of Discord and Slack's
| selling points. Slack login is entirely corporate controlled.
| Discord just works with one login across communities. These
| products are not popular in spite of their terrible privacy
| patterns, they are popular because of characteristics that
| intrinsically have terrible privacy patterns.
| colordrops wrote:
| Would should people who want to have productive group chat with
| privacy use then?
| rakoo wrote:
| Any client/server based app for a company-controlled
| replacementt The server manages rights and auth.
|
| Anything that accept OIDC or is federated for the second.
|
| Matrix doesn't totally fit the bill yet, but zulip does, so
| that's what you should install.
|
| But the one that surprisingly seems to be the best is
| probably email. We don't have the proper MUAs yet, but
| deltachat (https://delta.chat) shows that there is no reason
| for us to be limited to decades-old paradigms and should
| reinvent ourselves.
| komali2 wrote:
| What is a MUA? All results consider it "makeup artist."
| rakoo wrote:
| "Mail User Agent". The name is a parallel to browsers who
| also are called "User Agents"
| badrabbit wrote:
| Why can't the login be corporate controlled for Quiet?
| jona-f wrote:
| I think they are aware. Let the corporate crapsters do their
| thing and let us have our thing. To me, a community that relies
| on discord or slack is a red flag. I would really like
| something like this to become the default instead. Long live
| irc!
| tmpX7dMeXU wrote:
| Nothing about this is IRC. It is undoubtedly sacrificing a
| lot of things that the vast majority of people look for in
| multiplayer notepad, for properties that are sought after by
| privacy wonks. Mind you, IRC barely if at all addressed these
| "concerns".
| hardware2win wrote:
| Irc? That privacy nightmare giving IPs?
| Bu9818 wrote:
| You can hide it from other users by using a cloak (which
| some servers enforce on all connections), if that's a
| concern (but I don't think it's much of a concern). If you
| want some anonymity from both the server and users you're
| probably already connecting to the server from Tor (or
| maybe a VPN if it's blocked). OTOH discord is
| difficult/impossible to use from Tor Browser due to phone
| number requirements on suspicious connections and email
| verification when changing countries, which sucks.
| jona-f wrote:
| Yes, and on top of that i don't have to use a javascript
| enabled browser or some proprietary app, instead i can
| chose between many minimal and foss irc clients.
| hardware2win wrote:
| Discord is centralized which makes it safer than self
| hosted solutions
| jraph wrote:
| > To me, a community that relies on discord or slack is a red
| flag
|
| In which sense?
|
| I boycott both tools, but there are many respectable
| communities relying on them (unfortunately).
| tourmalinetaco wrote:
| To me, particularly in the FLOSS sphere, it belies a
| certain level of amateurism. Particularly when it is the
| primary method of "support". As a place of community, it is
| fine enough. As a place for technical questions? Stop
| trying to fit a square peg in a round hole and grow the
| fuck up. Especially since it makes indexing these solutions
| nigh impossible, even within the Discord app itself,
| meaning any effort put into fixing them is meaningless.
| Kiro wrote:
| So what should they use instead?
| tourmalinetaco wrote:
| For support, ideally something actually indexed like
| Github/Gitlab. I don't want to have to use their Discord
| to sort through hundreds of questions that failed to get
| answers to finally get to the one solution I need, when
| on a git site I can simply search the issues and find X
| solution away from all the chaff, since they're all
| labeled as "duplicate of X".
|
| Indexing is still a problem for social servers as well,
| but unfortunately there are no alternatives. The only
| current solution is to use bots to upload archives of
| public channels to say the Internet Archive.
| komali2 wrote:
| g0v is full of a lot of heavy hitter hackers that run a
| lot of their own software (including the full gamut of
| federated software), but a slack server is maintained
| because that's how the "normies" commonly interact with
| g0v as a community. Not everyone in the community is an
| engineer or technically savvy, and unfortunately a lot of
| these tools really aren't noob friendly. Yes, even IRC.
|
| Getting someone on the g0v slack is as easy as giving
| them a link. The entire experience is straightforward
| from there.
|
| Maybe one of the federated softwares is to that point and
| I don't realize it, I deploy a lot of federated software
| but I haven't done a chat application in a long time.
| tuyiown wrote:
| > Let the corporate crapsters do their thing and let us have
| our thing.
|
| I think this just cannot work if this is called alternatives.
| GauntletWizard wanted to specifically point this out: it's a
| mistake to think that the core functionality of slack and
| discord is just chat rooms & messaging, their mechanisms that
| implies terrible privacy are part of the core, and you can't
| expect users to dissociate messaging from the rest and call
| it a replacement.
|
| +1 for having <<our thing>>, but promoting it by bogus
| comparison or replacement is setting it for failure.
| throwaway290 wrote:
| If you don't need Tor, IPFS or P2P, Zulip is a much better open-
| source alternative.
| dijit wrote:
| +1 for Zulip.
|
| It's "ugly" and thus people really don't like it over slack.
|
| But it's _probably_ the best chat system available right now if
| you lean in to web tech.
|
| All I'm missing is the ability to create google meetings from
| inside the UI.
|
| And the mobile app is _complete_ crap, but they 're making a
| new one I heard.
| throwaway290 wrote:
| If you self-host I think you can implement Google meetings
| integration in no time. It's just Python. And integration
| with Jitsi is built-in...
| lionkor wrote:
| Looks really interesting! Huge shame there isn't any native
| client, but at this point, I wouldn't even know what stack can
| still produce a native client without being shunned by HN ;)
| meiraleal wrote:
| what would be a native client? They need the nodejs server in
| the client so Electron and React Native are the platforms
| needed to support their architecture.
| lionkor wrote:
| A native client would usually, for the most part, be written
| in a language native to that OS, and usually compiled. The
| discerning factor is that native apps, or any apps which use
| (actually) native GUI frameworks (as opposed to gpu rendering
| their own), integrate much better with the OS
| meiraleal wrote:
| This is the goal of React Native Desktop, not sure how good
| it is.
| holmesworcester wrote:
| (Quiet founder here)
|
| LOLOL. Ask HN: "How to produce a native client without being
| shunned by HN?"
| lionkor wrote:
| I mean really - the obvious, most featureful and well known
| one would be C++ with Qt or something, but thats way too
| unsafe (says the crowd using Chrome which is mostly C++).
|
| Rust doesnt have any mature GUI frameworks, and Lisp is
| probably the best choice here (for some reason).
| k__ wrote:
| I recently turned a HTTP service to an Onion service (i.e.,
| running a service on Tor without exit node) and it was
| surprisingly simple and low effort.
|
| Tor comes with a bunch of features out-of-the-box that are really
| convenient, like NAT punching or encryption without SSL
| certificates.
| huggingmouth wrote:
| This is what I really like about tor services. The ease in
| which I was able to host a blog off my heavly-natted phone
| internet uplink blew my mind about a decade ago. (Granted my
| excitement was quickly ruined by how fast my newfound pocket
| server ran out of juice).
|
| Today we have better options for hosting but none for dns and
| encryption. DNS+TLS doesn't come close to the security and
| reliability provided by having your address be your public key.
| In fact, and don't think any addressing scheme does.
|
| Offering your service as an onion service or at least making
| your (secured) admin panels accessible via tor is a no brainer
| in my opinion. No other entity can accidently block access as
| long as you have the private keys and tor is up.
| k__ wrote:
| _" making your (secured) admin panels accessible via tor"_
|
| Very good suggestion, thanks!
| holmesworcester wrote:
| (Quiet founder here) Yes! This is very underappreciated!
| Tor is like the Internet we all dream of having: forever
| addresses for everyone, with built-in hole punching.
|
| Tor startup and onion address connection times can be slow,
| but this is improving!
| jqpabc123 wrote:
| Ever notice how most things P2P aren't really P2P?
|
| Like here for example, there are still servers involved running
| IPFS and Tor.
| benlivengood wrote:
| There are still intermediate third-party routers between ISPs
| in any P2P system with less than a full mesh wireless network.
|
| Ham radio and audible conversation through the atmosphere are
| probably the only pure P2P connections.
| holmesworcester wrote:
| (Quiet founder here) We actually don't use any of that server-
| based IPFS infrastructure at all. Since Quiet is built on
| closed, private IPFS networks that are specific to each
| community we don't touch the global IPFS network.
|
| I think it's fair to call Tor a peer-to-peer network,
| especially if you don't use the exit nodes, which we do not.
| Yes, it's a peer-to-peer network with some special roles and
| generous volunteers who run always-on nodes, often on
| professional infrastructure. But Tor's design is peer-to-peer
| and Tor has paid thorough attention to the job of limiting the
| power of each node to harm the network, spy on users, etc.
|
| But yes, it's an excellent observation, and I totally agree
| with you that building real-world peer-to-peer networks with
| today's Internet and the world as it exists right now does
| require some compromises!
|
| The trick is to make sure those compromises are worth it and
| don't harm the goals you are trying to achieve. For us we're
| pretty confident they don't. Right now, Quiet lets you download
| a client and have a shared community space on the Internet with
| others that does not depend on any one entity's infrastructure.
| And no one, including us, has any special kind of technical
| control over what you do or say there. And you don't have to
| bring your own server (or have a friend with a server) to
| benefit from this freedom and power.
|
| These properties seem very significant to me, and that
| motivates me to keep chipping away on Quiet, despite the fact
| that things aren't always as pure as we might like them to be
| :)
| [deleted]
| edpichler wrote:
| A bit off-topic: who else misses the UX we had back in the days
| of Google Talk?
|
| It was simple, light, beautiful, distraction free, user centric
| and fast.
|
| https://imgur.com/nf6gguY
| kybernetikos wrote:
| And had bridges across to other systems and POTS! It was
| amazing. Curse of google though. They replaced it with 4 other
| non-interacting chat systems, none of which were as good.
| throwaw12 wrote:
| who is the target audience for this product? if companies,
| imagine the discussion they need to have when your communication
| channel relies on random machines vs single company with SLA/SLOs
| + bunch of engineers employed
|
| For enthusiasts maybe good, eventually maybe there will be ISP
| like providers which can guarantee hosting these nodes
| Manfred wrote:
| That's the cool thing about open source I guess. The target
| audience starts with the initial developer(s) who want to build
| it for their own reasons. Then others may find it and use it
| for their own purposes, even if it's just for education.
| nine_k wrote:
| I'd say that the target audience is (1) people who have some
| secrets to share among them, and (2) people who pretend they
| have such secrets, or just enjoy the feeling of extra privacy.
|
| The (1) may be good guys like whistleblowers, or journalists
| under oppressive regimes, or less so, like black market traders
| or gangsters. Also, a whole spectrum in between.
|
| The (2) are kids of all ages who love to play. If nobody plays
| with new tech, how can it even advance?
| totetsu wrote:
| Who Is the Makers of this product is what i want to know also,
| because its not written anywhere.
| yankput wrote:
| If all the users in the chat are offline, the chat is gone,
| right. Because it's decentralised so there is nowhere to take the
| messages from? As there is no "cloud"
|
| edit: ahh yeah it's in the FAQ in "session comparison"
| Asooka wrote:
| I wonder if it wouldn't be easiest to "just" have phpBB hosted on
| an .onion service and build a frontend to that.
| bogwog wrote:
| I just downloaded it and was surprised at how simple the whole
| process was. With technobabble like "Tor", "IPFS", "OrbitDB",
| "P2P", etc I was expecting to have to read through a manual and
| set up some complex stuff, but no. I just downloaded the app,
| picked a name for my community, and picked a username for myself.
| That's faster, easier, and more private than Discord, Slack, etc
| which require you to enter an email address and phone number.
|
| There has to be a catch to this, right?
| holmesworcester wrote:
| (Quiet founder here) Yes! Onboarding in a p2p app can actually
| be _easier_ than onboarding to a centralized app like Slack,
| and _much_ easier than onboarding to a federated app like
| Matrix (where users need to have a notion of what a homeserver
| is to not mess up.)
|
| The catches are many, but inherently solvable!
|
| 1. You have to be online for invitees to initially join your
| community. We have a release planned this week that will
| relax/mitigate this.
|
| 2. Sometimes it will take 20 or 30 seconds to connect to a peer
| over Tor, and this is longer than most users expect.
|
| 3. Mobile is much harder than desktop and our mobile apps
| aren't in as polished a state as the desktop app. iOS
| background tasks and Android long-tail device support are hard!
|
| 4. iOS will almost definitely depend on a centralized push
| notification service for reliable notifications.
|
| 5. If you send a message and nobody is online, nobody will get
| it until you and someone else are contemporaneously online.
|
| And there are more. But your point stands! Quiet can offer a
| superior onboarding experience in a lot of ways, and it can be
| snappy for day-to-day use. And thanks for taking the time to
| try Quiet and relaying this lovely impression to everyone here!
| chevy90 wrote:
| Does it make sense to have an option to disable Tor and just
| use normal network since all other features are appealing.
| lcnPylGDnU4H9OF wrote:
| How are naming conflicts handled? I could imagine community
| names might need to be unique across the service and
| usernames unique per community but I wonder if there's
| something smarter which might allow seeming duplicates which
| are otherwise differentiated. One example is -- I guess not
| exactly "smarter" -- Discord with the user#numeric_id
| pattern.
| makeitdouble wrote:
| Isn't P2P for group messaging a weakness more than an asset,
| especially if the messages have any importance (I'm thinking
| corporate settings for instance). Or am I missing some central
| piece that still acts as common server ?
|
| I'm imagining being a dev in a team, I'm the only one connected
| on a saturday night and and my laptop bursts in flame. Wouldn't
| it be nice to go to a fresh laptop, just log in the central
| server and have access to everything without waiting for someone
| to get online to sync the whole history of all your chats ?
|
| And of course, having to deal with the whole history in the first
| place feels like a pretty heavy issue. Using this system for a
| year or two with a few dozens of people would lead to crazy
| amounts of messages needing to exist on every client.
| earnesti wrote:
| You can run one server instance that is always online? Less
| stress because no need for high availability.
| happybeing wrote:
| p2p does not necessarily imply the limitation you describe.
|
| I don't know how Quiet uses IPFS but a truly decentralised
| storage system such as the design of Safe Network can hold data
| locally (eg using CRDTs) and/or in a decentralised, always
| accessible p2p network of nodes.
|
| Chunking and redundancy ensures data is always available
| without the need to centralise.
| holmesworcester wrote:
| (Quiet founder here.) The OP's edge case is an interesting
| question and one we've given a lot of thought to!
|
| For privacy reasons Quiet does not use the global IPFS
| network and instead gives every team their own network. This
| provides a clearer story around metadata privacy protection
| and (most importantly!) ensures that timed deletion of
| messages is practical and meaningful. Disappearing messages
| are a must-have for many threat models, and deletion is much
| more meaningful when you're trusting clients within a
| community you trust to delete the messages, rather than
| trusting every peer on a global network anyone can join.
|
| So there are advantages to having an organization-specific
| network, and the problem the OP highlights does come up if
| there are no other devices online. Here's how we think about
| that edge case of "No other devices are online and I need to
| send this message before I sign off and know someone will see
| it as soon as they sign on":
|
| 1. If a team is worried about this, a computer under a desk
| or an Android device in a corner running Quiet is _much_
| easier to set up and maintain than a server, and it is
| trivial to add as many of these as you want in diverse
| locations until you are confident in the uptime, e.g. that
| any one of these devices could get unplugged or suffer an
| internet outage and it probably won 't correlate or matter.
|
| 2. When running a server that does something important you
| need to have some separate monitoring setup like Pingdom and
| have someone on pager duty if you want to achieve respectable
| uptime. With Quiet, we can build that monitoring into the p2p
| app itself. We haven't done this yet, but picture a feature
| where the app shows you the uptime stats of your network and
| you designate nodes that should always be online. The network
| itself could notify you of any disturbance that threatens
| uptime, e.g. if one of your designated always-on nodes starts
| misbehaving.
|
| 3. People who don't want to worry about this can pay us or
| someone else to run a server for them and we'll make this
| easy. But it's better than depending on a centralized service
| because in most cases everything will still work if our
| server goes down, and they won't be dependent on us the way
| people depend on cloud SaaS, because Quiet is easy to fork
| and the fork will work pretty well out-of-the box in most
| cases with no infrastructure required.
|
| 4. It doesn't take many Android phones in full-p2p mode to
| give you a lot of often-online nodes, so continuous liveness
| could emerge organically in larger communities and it becomes
| more about showing metrics to give people confidence that
| this is the case (and making the experience on Android really
| nice--optimizing battery life, exposing choices to the user,
| etc.)
|
| 5. A small Quiet community without enough resources or
| participants to have enough always-on nodes could designate a
| larger, busier, more infrastructure-stable Quiet community as
| a trusted helper. The other community wouldn't see the
| plaintext of messages but it could support message syncing
| and provide other helpful resources. What I like about this
| is that well-resourced or tech-savvy communities could
| support other aligned communities without the hassle and
| responsibility of running a server.
| snowram wrote:
| A chat platform with only textual chat and file sharing isn't an
| alternative to Discord nor Slack. It is barely a slightly better
| version of IRC. Unfortunately many messaging softwares seem to
| not understand what feature parity is.
| j_maffe wrote:
| They say so in the project description. I think they understand
| what constitutes a group messaging app. It is, however,
| something that can be built upon and improve. That's how open
| source works, you have to start with just the basics. Still,
| it's a very good step in the right direction.
| holmesworcester wrote:
| (Quiet founder here.) Yes, this!
|
| Based on our research with users who need sensitive
| communications, a working Slack or Discord alternative
| _without_ video calling is desperately needed by some teams
| right now. (For example, teams who want end-to-end encryption
| but have a big community with highly specific moderation and
| vetting needs.)
|
| So starting with text, images, audio messages, etc. can get
| us a foothold and we can build from there.
|
| Just getting Quiet working as reliably as a centralized chat
| app on iOS and Android and finishing things like multi-party
| e2ee group chats with multiple device linking is going to be
| a big lift that could easily take us 6 months or more. Group
| video calls can come after that if our initial early adopters
| are asking for it!
| ThatPlayer wrote:
| I don't agree that you need feature parity to be an alternative
| though. If your use-case is only text chat and file sharing,
| then it is an alternative.
|
| LibreOffice is still an alternative of Microsoft Office without
| having all the features. Firefox is an alternative of Chrome
| without WebHID or Web Bluetooth.
| Brybry wrote:
| Discord's key features are chat _and_ VoIP. File sharing is
| barely meaningful, except that it means not needing to use
| external image hosts for gifs /memes/pet pics.
|
| Discord's initial pull was from gamers who were using
| teamspeak/ventrilo/mumble + twitch chat and maybe IRC.
|
| If it doesn't do VoIP then it's not a viable alternative to
| Discord.
|
| It'd be like if LibreOffice couldn't save new files or if
| Firefox couldn't render images or video.
| robinsonb5 wrote:
| > If it doesn't do VoIP then it's not a viable alternative
| to Discord.
|
| It is, however, a potential alternative to one common use
| case for Discord, namely: "What we really wanted was a web
| forum, but this is easier."
|
| This describes all 15 of the Discord servers I'm currently
| on.
| executesorder66 wrote:
| If you really wanted a (I am assuming free AND 0 setup)
| web forum, why not use reddit instead? It is at least an
| actual forum, that is also web searchable. And like
| discord, it is free and you don't have to bother with the
| hosting/setup.
|
| What does discord offer that reddit doesn't? (In terms of
| being a web forum)
| robinsonb5 wrote:
| That's a good question - I suspect the answer might be
| "trendiness".
|
| (My only experience of Reddit is from Boogle searches
| landing there [an immediate point in its favour over
| Discord] and it appears to be pretty heavyweight, loads
| down the browser even more than Discord, and has ads
| everywhere - maybe the experience is better if you
| actually create an account and log in?)
| ThatPlayer wrote:
| Not all use-case requires both chat and VoIP though. I
| basically never use chat in my friends servers because
| we're on VoIP. Mumble is an alternative in that case. On
| the other hand I never use VoIP on servers I'm in for open
| sourced projects or other general hobby servers because
| it's a bunch of strangers and people asking for support.
| circuit10 wrote:
| I'm someone who uses Discord but (almost) never uses voice
| chat. To me it's a text chat platform. This isn't true for
| everyone but I feel like it is for a lot of people
| Brybry wrote:
| But think about why you're now using Discord instead of
| IRC or a forum: it's because of the users who were also
| pulled in for the core VoIP feature and because users
| would rather use one program than multiple.
|
| I didn't stop using Mumble or IRC because they couldn't,
| combined, meet my needs. I even prefer them to Discord on
| a principle basis.
|
| But everyone I wanted to communicate with moved to
| Discord because it was easier -- as it had _both_ core
| features which are necessary for gamers.
| croes wrote:
| >But everyone I wanted to communicate with moved to
| Discord because it was easier -- as it had both core
| features which are necessary for gamers
|
| That's the real reason why you use Discord. Peer
| pressure.
|
| Discord is in no way a replacement for a forum
| circuit10 wrote:
| The network effect is obviously a big part of it, but
| it's also that IRC is extremely barebones and difficult
| to use even for messages.
|
| I'm quite a techy person and I even wrote my own frontend
| to Discord a while ago, but I've struggled with things
| like bouncers and authentication to the point where it's
| just easier to set up a bridge to Discord and use that
| when I need to use IRC, and then I miss features like
| editing and profile pictures (there are proposals to add
| these things to IRCv3 but they aren't widely supported)
|
| IRCCloud seems to have a good solution to some of this
| but is paid
| lucideer wrote:
| Understanding feature parity is about:
|
| 1. Can the protocol support it (well)
|
| 2. Is the tech mature enough / is there enough contributors to
| ensure the client adds support
|
| For a new tech only the first bullet point is relevant - from a
| brief scan it seems like a hopeful but emphatic yes.
|
| I guess there's a third soft question which is, does the
| project have the branding, polish, marketing clout to gain
| traction: much harder to gauge but looks polished at least.
| lolinder wrote:
| What you're defining is _possible future_ feature parity, not
| feature parity.
|
| A project does not have feature parity until the features are
| actually built--promises that the features are possible and
| if you really wanted it you could build it yourself are nice
| in their own way, but they're not features.
| lucideer wrote:
| You're technically correct (the best kind of correct), but
| in the context of this comment thread the comment I was
| replying to said:
|
| > _many messaging softwares seem to not understand what
| feature parity is._
|
| That implies either no intent to implement feature parity,
| or having had enough time & resources to do so without
| bothering to. Neither of those things are the case here -
| hence my breakdown.
|
| I've edited my comment to better address your particular
| point though, thanks.
| holmesworcester wrote:
| Quiet founder here!
|
| First, the big advantage of Quiet over IRC is that Quiet has
| eventual consistency built on a CRDT, so you'll sync messages
| sent while you were offline. In a team chat setting this is
| really useful and was one of Slack's big draws when it
| launched, as I remember it.
|
| Re: video calling -- end-to-end encrypted voice and video calls
| (or channels, huddles, what have you) are actually something we
| plan to add someday, as we've had users asking for it. Right
| now many voice and video calls are at least partly peer-to-
| peer, so with some caveats a p2p video calling solution is
| actually more straightforward than p2p chat. The caveats are:
|
| 1. We wouldn't want to use Tor, at least in its current form,
| because its multiple hops and lack of UDP support will increase
| latency, so you wouldn't get the same metadata privacy.
|
| 2. Larger group calls (>10 voice participants, >3 video
| participants) may well require a server, since the standard
| solution for pure p2p group calling is for all participants to
| stream pairwise to all participants, so the number of
| participants is limited by the upstream bandwidth of the
| slowest participant divided by the stream bitrate.
|
| 3. Even small group video calls often require a relay server
| sometimes, because roughly 10-20% of peers in real world
| settings cannot make direct connections to each other even with
| holepunching techniques. (A classic scenario: two peers on the
| same public wifi, when the router's security settings prohibit
| local connections, will need a reliable external server to send
| all the data.)
|
| So our current plan is to offer voice and video calling (and
| any other features that require a server, like file storage
| beyond the capacity of the network's devices) as a paid
| subscription feature.
|
| Picture a freemium SaaS product where the free version is open
| source, forkable, and fully reliable in its p2p form without
| any support from us. This gives users a lot of power to keep us
| honest, but it would let people pay us for stuff you really
| want a server for.
|
| All that said, maybe somebody will come up with a great p2p,
| large-group video calling solution with reliable decentralized
| holepunching and we can use that approach! (But I'm not holding
| my breath!)
| tyzoid wrote:
| What about Veilid?
| holmesworcester wrote:
| Veilid is a recently announced, general-purpose peer-to-
| peer Stack. We're excited about it!
|
| We would _consider_ switching away from OrbitDB
| /IPFS/Libp2p/Tor for a less mature peer-to-peer state
| syncing stack if it offered the following as first-class
| features in addition to what we have, had credible
| longevity, and ran well on desktop and mobile:
|
| 1. Deletion
|
| 2. Encrypted groups with removal
|
| 3. Support for linking multiple devices, and removing
| devices
|
| 4. Support for partial syncing / lazy loading.
|
| It would be _really_ nice to have all of these things out
| of the box, alongside state syncing and BitTorrent-style
| file transfer (which we have now.) Veilid is still new so
| we haven 't assessed it yet, but that would be our
| criteria.
|
| My general perspective on general purpose peer-to-peer
| stacks (which I understand Veilid to be) is that it will be
| very difficult to build meaningful general purpose
| platforms until we have more examples of popular desktop +
| mobile peer-to-peer products with large numbers of users in
| the wild that would let us identify all the things a
| general purpose stack would need to have, and that right
| now the best thing to do is build single-purpose peer-to-
| peer apps in whatever way you can (whether it's by building
| your own non-general stack or cobbling together existing
| building blocks as we're doing) and struggle to find
| product market fit!
|
| The way I think about it is: would you have been able to
| build Heroku before there were a few successful production
| Ruby on Rails apps with product-market fit? Probably not!
| So we shouldn't expect to be able to build useful general
| purpose p2p stacks without clear examples of successful p2p
| products with product-market fit.
| MayeulC wrote:
| Hmm, it feels like a CRDT + any overlay network (This is
| probably how you use tor or IPFS p2p) would get you
| there. Matrix p2p is developing pinecone [1] as an
| overlay network, which seems very aligned with your
| needs, though, as you say, it is less mature.
|
| Well, pinecone/yggdrasil/cjdns/tor are only part of the
| question, as they provide encrypted E2E connectivity. You
| still have to build on top of it to handle groups and
| lazy loading. They do solve routing though, so you can
| just try to send packets to every group member (like
| Matrix does). For a more efficient implementation, it
| would be nice to have multicast/unicast integrated in the
| overlay network at the protocol level. API-wise, it could
| be made as simple as sharing a private key with a group:
| multiple peers with the same address would then receive
| the same packets.
|
| In any case, I feel like working together with Matrix
| (/new vector) on pinecone would help both of you.
|
| [1]: https://github.com/matrix-org/pinecone
| holmesworcester wrote:
| I've been following the P2P Matrix work intermittently
| but closely. Matrix clients are so much more mature than
| ours, so having a first-class P2P mode in Matrix would be
| a solution to this whole problem.
|
| 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.
| Arathorn wrote:
| The reason that P2P Matrix (arewep2pyet.com) exists is
| precisely to provide a 1st class P2P mode to Matrix -
| it's not just for awesome reliability and network
| resilience, but for easier onboarding; killing off
| public-service homeservers like matrix.org; etc. The
| onboarding and identity piece is covered by MSC4014
| (which just got implemented in Dendrite.)
|
| However, you're totally right that our main focus is on
| the federated use case, because that's where everyone is
| today, and its own fair share of Hard Problems (e.g.
| reliable decentralised E2EE, byzantine-fault-tolerant
| conversation replication, decentralised ACLs, lazy-loaded
| conversation state) before we chuck P2P into the mix too.
|
| The P2P Matrix project is currently focusing mainly on
| MSC4014 (i.e. pseudo-IDs, account portability, multihomed
| accounts) which benefits both P2P and normal Matrix...
| although I'm hoping that we'll get back to Pinecone &
| actual P2P work eventually (especially if someone
| explicitly funds it).
|
| Meanwhile, it's super cool to see the progress on Quiet
| and OrbitDB. It's come a long way since Orbit launched at
| the 2016 Decentralised Web Summit, and I'm glad to see
| the tech is still progressing. FWIW, We did the first
| versions of P2P Matrix on top of libp2p (but then
| switched to Yggdrasil and then Pinecone in order to work
| with a monolithic stack, for better or worse). Might be
| interesting to figure out how the projects could interop
| in future :)
| eTomte wrote:
| I'm a Matrix enthusiast, run my own homeserver and I've
| been playing around with Quiet today.
|
| It has nowhere near the features of Matrix at this point,
| but it is useable and I'm having fun with it, and I
| really look forward to see progress on both projects. :)
| 37469920away wrote:
| Always good to have alternatives. Thanks for your work and
| good luck.
| holmesworcester wrote:
| Thanks!!
| h0p3 wrote:
| Thank you for this gift to humanity.
|
| * I'm glad to see you are thoughtful about many protocols
| here. Will you be adding i2pd support?
|
| * Could you make explicit for us what parts of this tool are
| the least decentralized?
|
| * Do you need computational donations to the network? How can
| I assist?
|
| * Do you intend to provide users complete control over
| private/public keys within the interface?
|
| * Will you be providing significant command-line access to
| the tooling?
|
| * How far have you attempted to scale this up?
|
| * Will you be working toward collaborative text environments
| like Etherpad? Latency seems too high for that, right?
|
| * Do you intend to enable the synchronization of larger sets
| of files, something like mutable torrents?
| holmesworcester wrote:
| > Thank you for this gift to humanity.
|
| 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?
| h0p3 wrote:
| > we have so many bigger fish to fry!
|
| I can see that. Your roadmap makes sense to me. My
| [[wife|k0sh3k]] (without having seen your roadmap) picked
| out many of the same points as reasons she must wait to
| use it for her library staff. I appreciate how you must
| triage with the resources you have. Most of what I have
| to say isn't going to be as important to the non-
| poweruserbase you are trying to capture (and rightfully
| so!), so please take what I have to say with a grain of
| salt. You obviously know what you are doing. Reading
| through your account, I think you already know what I
| have to say here.
|
| > Would desktop-only i2p support be useful to you?
|
| Yes, and not just because I think it's important to
| contribute back to the network as a regular user. It
| would be especially nice with command-line tooling, and
| you can pickup UDP support. I've encountered plenty of
| failures on Tor (and you have too), and there are many
| I've encountered who I believe are rational in their
| desire not to be so reliant upon that network. I'd also
| be happy to use i2p on a mobile device just in case I had
| somewhat convenient control over when that occurred. If
| you provide logical accounts (where my decentralized
| identity can be wielded by multiple cooperating devices),
| then i2p becomes even better. Retroshare's use of both
| Tor and i2p have demonstrated the value of diversity here
| to my eyes as well. I'll add that something like
| multiplexing over multiple Tor or i2p tunnels could
| significantly improve throughput performance (a difficult
| place where you might be able deliver in some cases where
| no one has).
|
| However, I think your focus on mobile is more important
| (and I say that with a deep-seated grudge against
| phones). You serve the poorest on the planet by targeting
| mobile first. That isn't to say that you don't have any
| use for desktop users to assist on this network, but I
| can see why i2p, among many of my suggestions, should
| take a backseat. `/nod`.
|
| > It would be awesome to have a p2p github alternative
| that could ship builds over BitTorrent or IPFS
|
| I understand you've been around the block, so please
| ignore my gibberish. To my eyes, you're also building a
| serious competitor to [[P2P Matrix|2021.11.17 - HN Log:
| Arathorn & P2P Matrix]], which is still under
| development. I'll mention that Radicle may be worth your
| consideration. The functionality of [[DarkMX]] is worth
| your time as well (it is closed source, but its creator
| is one of the few with the right to ask us to trust him
| [even if I stand in disagreement]). I know some, like
| [[Ian Clarke]], will claim it is better not to "focus too
| much on competitors, better to focus on the needs of
| users," however, given the specialization of this tool, I
| think there's something to be said for having tasted the
| alternatives. [[Aether]] may be a direction you could
| eventually go, but I understand that isn't your immediate
| target; I don't know if protocol design decisions now
| might affect the future of such a thing.
|
| > Beyond participating in Tor, Quiet does not allow you
| to help any network you're not a member of
|
| `/nod`. I wonder if it is feasible for Quiet to have
| something like the Encrypted Key option in Resilio Sync,
| enabling one to seed in swarms without knowing the
| contents. There are some cases where it's useful, though
| there are tradeoffs.
|
| There may come a time where you've decentralized to the
| point where it hurts too much, and you'll have to
| centralize until it works. I wonder if there are cases in
| which randos must hold at least metadata for others or
| act as proxies (I understand that Tor solves many
| problems for you). [[Tox|Toxcore]] is an exemplary tool
| in part of this space you're solving, and even they
| haven't solved some of these problems. Seamless
| multidevice and offline messaging are dealbreakers for
| many people.
|
| > If you have access to a large number of machines,
| rigorous performance testing with hundreds of nodes could
| possibly be helpful?... manual and automated testing on
| many diverse Android devices; that would be helpful!
|
| I'll be thinking about that then. NixOS with solid
| orchestration on a beefy machine (I'm not sure if zswap
| would assist here, but memory seems a serious bottleneck)
| may be able to push hard. There's probably no way around
| using a lot of machines unless a much thinner client were
| feasible. The nice part is that donations might allow you
| to control the machines remotely while dogfooding.
| h0p3 wrote:
| > Know anyone?
|
| My family tests this type of software often enough. I
| know my daughter, [[j3d1h]], desperately hopes for a
| secure replacement to Discord for her [[friend]] groups.
| She's sitting on the couch with me right now writing up
| what she's missing most in your software. Here is what
| she said:
|
| ``` just my opinion, man -how
| are profiles going to work? do you have an individual
| username for each community, or will your profile
| eventually be the same across all the communities you're
| in? -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 -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
| -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
| -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 -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 -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. -a friends system
| is useful for this; maybe i don't want anyone i haven't
| marked as a friend to DM me -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) -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) -are voice and/or video planned, both in
| communities as well as dms? -muting + deafening +
| turning off camera, nothing in a voice/video chat should
| be mandatory (owners shouldn't be able to *un*mute
| someone, but owners muting others can be useful)
| -maybe i want to mute that user, but allow everyone else
| to hear them? turn this one up and that one down on my
| end? -audio controls that make sense. if there's
| a layer of noise cancellation, leave the option to turn
| it off in case it messes with your audio, etc.
| -taking microphone input as it is works just fine, though
| i can see some users disliking that (mostly people who
| don't know how/can't modify their settings *outside* of
| Quiet) -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 -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 -user
| discovery outside of communities, preferably just typing
| in a username they send you elsewhere? -will it be
| possible to delete an entire community? can an owner do
| this in situations where members don't agree?
| -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) -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? -any
| distinction between a community and a DM with 3+ users in
| it? -i don't personally see the point, but some
| apps have this nitpicky, visual polish,
| further off details -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? -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)?
| -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
| -channel organization and categories; i don't always want
| the art channels open, i want #announcements at the top,
| etc. -messages marked as read/unread can be useful,
| something to carefully think about -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
| -client side unread; i'd like to pick up from the last
| message i read in this channel -having channels
| visually marked that there are unread messages is nice
| -keyboard navigation beyond pressing tab is super useful;
| a screen you can reach to describe these shortcuts is
| equally so
|
| ```
| h0p3 wrote:
| > 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.
|
| I hope you'll consider adding more control over the keys
| within the application itself. Ideally, I should be able
| to generate my own private key from scratch, paste it in,
| and recover at least a bare identity (this can be
| bootstrapped further). I should be able to hand someone
| just a public key for any of the functions we may need;
| these keys should be easy to copy and paste into and out
| of the application. Key control pedagogy is not fun, but
| it's ultimately required for us to own the means of
| production; I think you've a difficult usability fence to
| straddle here, and perhaps a ladder to construct.
|
| > 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.
|
| What feasibility concerns do you have?
|
| > 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.
|
| Lawd, I'm a preachy sumbitch here. I have yet to find a
| tool that I think does this really well. It's probably
| going to be crucial to have not only sane default but
| strong controls available to users. I am pretty worried
| you won't escape some elements of federation or at least
| asking users to rely upon friends or additional devices.
| Can kids across the planet safely pirate arbitrary files
| on their phones together? That's the bar, homie. You know
| whom we serve, and I think you're doing it. I [[hope]] we
| don't fail.
|
| Do not make the mistake that [[Aether]] did on retention,
| please. Users must have the opportunity to pin/seed with
| complete persistence. Any tool (e.g. [[Session|2021.09.25
| - Computer Musings: Session Fucked]]) that has forced me
| to lose my identity or my messages is not a tool I'm
| going to recommend to anyone again. I understand you may
| wish to minimize the prices the average person must pay
| to manage their data, but at some level, there is so
| substitute for having the user be responsible for it.
| Joining a room without having to traverse and download an
| entire graph of content will be important.
|
| Low-end phone performance (not the mobile devices you and
| I can afford) is such a hard and important problem that I
| wouldn't be surprised to find that what you're making at
| the moment is ultimately a prototype. I obviously
| [[hope]] I'm wildly wrong about that.
|
| > We would love to pursue this if our users ask for it.
| So far there isn't a strong signal that users need it.
|
| Then please ignore my desire. Your task is already
| absurdly difficult as it is.
|
| > 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.
|
| It's so interestingly phrased, I feel uniquely qualified
| to speak on this matter. I probably hold a contrarian
| position. This is obviously an imperfect way to do it,
| but I'll leave the tool up for a while; you'll find the
| link in this room (channel is your handle):
| ukkmcdhhymxki3plly2w7mkweafijihwhldwnmt6yzwan6rmtuin7zid.
|
| > But technically this would be a fun challenge and I'm
| sure we could build something great. There are other
| CRDTs we could use.
|
| Speaking of a narrow challenge, E2EE P2P Tiddlywiki isn't
| that far off. You might consider hitting [[Sir Jeremy
| Ruston|2023.08.08 - TW-Community: Hello]] up (TW5-Bob is
| also dope; and Jed would understand what you're doing
| well, imho).
|
| > This would probably be straightforward. What's your use
| case?
|
| I provide access to my constantly updating site (almost
| exclusively consisting of a single ~60MB html file
| growing at ~8MB of pure text a year on average) over
| multiple networks, and few are designed for such a thing
| (you're already got a foundation for something better
| than Zeronet and Beaker [both venerable projects,
| obviously]). I [[share]] mutable directories with many
| folk, some of whom I cannot [[trust]] (I often have to
| use Whonix). I need a turnkey multi-platform open-source
| replacement to Resilio Sync that people are comfortable
| using. I understand you will be limited by IPFS here as
| well; I can share 6TB of an evolving curated library
| using just a couple gigs of RAM on Resilio Sync (with
| selective syncing on mobile), and I can speedily and
| efficiently share my `/home/h0p3` (millions of files)
| across my devices with it as well. I hope to be able to
| recover identities, contents and all, seeded on these
| networks. Writing a Discord-killer is already a
| [[monster]] of a task (bless you), but mutable torrents
| with a solid chat-based community is where you can walk
| on water where no one else has.
| thewanderer1983 wrote:
| Have you considered lokinet? It may help for the video/audio
| calls.
| holmesworcester wrote:
| Yes! I've followed the progress of Loki/Oxen/Session since
| a talk I gave at HOPE 2020 surveying the field of p2p
| messaging approaches, and since then a mutual friend
| introduced me to the Session/Lokinet team and we had a
| great meeting.
|
| The Oxen/Session approach of having a bunch of crypto-
| incentivized, investor-subsidized always-on servers to do
| stuff for you is _very_ powerful and makes a lot of things
| easier. Where it really shines is supporting iOS devices
| where the OS gives you very tight constraints on how much
| CPU and time you can use to connect to a peer and sync
| messages. I true
|
| We decided to start without depending on a cryptocurrency
| or a cryptocurrency-incentivized network because I don't
| think we need it. I know some people _hate_ crypto too. I
| don 't but it keeps things cleaner to not depend on it.
| Also, when it comes to onion routing Tor is a lot more
| battle-tested and has many more eyes on it, so I'm fairly
| confident that it's superior to the extent we only need
| that piece.
|
| There is also some actual worrying ambiguity around what
| happens with lokinet if their coin price drops but their
| traffic goes up a lot. (Though the same thing could be said
| of Tor, swapping out "community support" for "coin price",
| so we may have to roll our own network in the future anyway
| or give users more options for connecting directly when
| they feel it's safe to do so.)
| LWIRVoltage wrote:
| This would be huge- but also a replacement forJitsi Meet,
| which just started requiring registration using google,
| Microsoft or Facebook accounts. So, anonymous E2EE( well,
| they used insertable streams, Firefox didnt have this fully
| implement Yet but was working on it, spurred on by jitsu
| meet, actually)
|
| Im a web browser accessible OR electron app form for any OS,
| open source, and totally anonymous, while able to host a good
| number of people all securely, for free, is not accessible to
| people anymore.
|
| ( there are other jitsi meet instances that likely will not
| require the same but this badly hurts nontheless, as they
| were perhaps the main free zoon competition in some ways.)
|
| https://news.ycombinator.com/item?id=37316959
|
| https://news.ycombinator.com/item?id=37381508
|
| You'll be filling that gap, and it is a badly needed one from
| an anonymity /E2EE functionality perspective.
| holmesworcester wrote:
| That's really interesting. Jitsi offers a React Native SDK
| and we were interested in using it (in e2ee mode) for
| Quiet. Twilio offers one too (FOSS on client side and
| Twilio SaaS on the server side) but it would be nicer to
| use Jitsi. If we only offered it to paying customers it
| would have the same downsides as using Jitsi though.
|
| One question: speaking for yourself and the use cases you
| know well, how much latency or call quality would you give
| up for anonymity? Would you give up video? Would old-school
| VOIP level lags between speakers be okay?
|
| Doing something like push to talk would be trivial now,
| over Tor. But an anonymous video call with lots of
| participants would be really hard. Sometimes I think about
| something in between... like a voice activated push to talk
| where everyone's audios are played continuously. But
| nothing exists like this afaik so it would be costly to
| explore.
| LWIRVoltage wrote:
| My apologies on my former post, the auto correct on my
| phone did a number.
|
| For the use cases I know, some quality loss wouldn't be
| to much of an issue, but at least rudimentary video would
| be desired. Lag of that sort wouldn't be too bad of an
| issue considering it'd be to maintain a level of security
| and privacy that is difficult to match.( Since Signal is
| still working on not needing to use phone numbers, to add
| a privacy/ anonymous benefit to it)
|
| I know both Jitsi Meet and Google Duo( now google Meet)
| have a bit of info out there about the challenges they
| encountered upon finding methods to implement multiple-
| person E2EE video chat.
|
| Duo had a cap of about a dozen give or take, callers at
| first before they could scale up. Jitsu added E2EE as a
| toggleable option after getting their initial product
| out- so this might be the sort of thing where it doesn't
| start out with lots of Participants, at the beginning.
|
| Finally, you mentioned exploring some of these options
| not over TOR. That might be beneficial for those seeking
| anonymity, since TOR usage has been used to fingerprint
| people when no one else on a network was using it. (
| VPN's and Bridges are other methods of course to plug
| that hole, but usually have to come from the user side at
| cost and some technical familiarity.)
|
| Push to talk is not something I've seen before- I take it
| the technical load would be less in that format?
| KoftaBob wrote:
| If we want to be pedantic about it, then let's call it an
| "Imperfect Substitute"
|
| https://en.wikipedia.org/wiki/Substitute_good#Imperfect_subs...
| meiraleal wrote:
| That's the magic of free software. It would only have feature
| parity so early on if it was VC-backed, which would not make
| any sense.
| busssard wrote:
| Its an opensource project. Instead of complaining, why dont you
| implement it? ;)
| hnarn wrote:
| Completely beside the point. The comment you're replying to
| was simply questioning the headline.
| j_maffe wrote:
| OP implies that the devs were the ones who wrote the
| headline though. They clearly stated that it is not (yet) a
| sound alternative to Discord.
| plastic_bag wrote:
| The About section of the repo literally says "A private,
| p2p alternative to Slack and Discord built on Tor & IPFS
| ".
|
| So the dev(s) are indeed claiming it's an alternative to
| both Slack and Discord.
| [deleted]
| qabqabaca wrote:
| He's not complaining about it missing the features he wants,
| he's complaining about it missing features of the products
| it's presenting itself as an alternative to
| derelicta wrote:
| As much as I hate to say that, they are right. If you want to
| be a significant competitor to centralized plateforms, you
| gotta at least do as much at them.
| meiraleal wrote:
| and from where would you start? How should the project be
| defined if they are yet not an alternative? The "soon to be
| if people contribute" P2P alternative to slack and discord?
| LoganDark wrote:
| This is an extremely toxic attitude and helps no one.
| mrd3v0 wrote:
| As a major supporter of free software, I can't believe how
| many times I encounter this reply. No, not everyone has the
| resources nor skills to dedicate to a random unknown free
| software project online.
|
| Criticism is helpful and can inspire others who do have the
| time and skills to direct or fork the project into something
| more useful.
| notpushkin wrote:
| Criticism can be helpful indeed; it's the form that
| triggers this kind of response. Let's try this one more
| time:
|
| > Very impressive project! It's neat that you can get this
| far without relying on any central servers at all.
| Personally though, I'm missing a couple more features -
| this only has textual chat and file sharing, while Discord
| or Slack have a lot more niche features. Achieving feature
| parity is a prerequisite for getting any user base
| nowadays, so I hope it is something team would account for
| before the 1.0 launch :-)
| _factor wrote:
| It's incredible how tone-deaf to their own tone of voice
| people can be.
| notpushkin wrote:
| This happens sometimes, yeah. We're all just mere humans
| after all.
| holmesworcester wrote:
| (Quiet founder here)
|
| I agree with the objection that not everybody can just
| contribute patches for major features to an open source
| project, and I think it's fair to say that the comparison
| to Slack and Discord is not 1:1 without voice and video
| calls (which we do plan to offer someday, FWIW) and to
| feel disappointed by that. Though I think when an open
| source alternative emerges it is usually understood that
| it could take a while to get to feature parity, and we
| try to be very clear about what Quiet already does and
| doesn't do yet on our homepage.
|
| That said, Quiet is written in TypeScript and built on a
| web stack almost every engineer is somewhat familiar
| with, so it's really easy to get hacking on, and we'd
| love the help. :)
|
| Here are the instructions to build Quiet desktop: https:/
| /github.com/TryQuiet/quiet/blob/develop/packages/desk...
|
| And here are some good first issues! https://github.com/o
| rgs/TryQuiet/projects/3/views/1?filterQu...
| notpushkin wrote:
| Agreed, the web stack should definitely help get some
| contributions. I might take a look too :-)
|
| Tangential but have you considered something like
| https://tauri.app/ instead of Electron for the app? (One
| of my major concerns with Electron apps is that every app
| ships and runs its own copy of Chromium - Tauri mitigates
| that by using system web engine instead.)
| holmesworcester wrote:
| We might switch to Tauri someday. Death-by-a-thousand-
| cuts is a very serious risk for us though, so we're
| trying to choose the most mature and widely-used tools
| whenever possible.
|
| As noted on our website, we still have a lot of work to
| do on security (including some open issues you could
| probably tackle! and thanks for expressing interest!!) so
| it will be a wonderful day when Electron's lag in staying
| up to date with Chrome security fixes is our most
| pressing security issue!
|
| In the meantime, if Signal chooses Electron that is a
| good indicator that, all things considered, it is a good
| choice for us. They have a lot more resources than us,
| are much farther along than we are, and they take
| security seriously.
|
| One immediate issue with Tauri, just to give an example,
| is that it would require us to worry about Safari quirks
| on Mac.
|
| I've also heard from projects in our space that the
| handling of platform-specific functionality outside the
| browser window is not as mature in Tauri as it is in
| Electron. This is totally understandable and Tauri is a
| great project with great goals, but the possibility of
| running into some deal-breaker Windows-specific issue,
| say, is scary.
| meiraleal wrote:
| Not everyone but thousands here in HN, I'm checking right
| now how to integrate it in my app and change the messaging
| platform to Quiet and maybe even the data sync between
| peers for other collaborative stuff
| pjerem wrote:
| That's not entirely true.
|
| Most companies use multiple products even if they could use
| less.
|
| As an example, most companies using Zoom also use Slack. So
| they don't use all the slack features although they could.
| Maybe because they think, for whatever reason, Zoom is better
| at conf call and Slack is better as chat application.
|
| The same is true with Teams, that basically any company owning
| office licences get for free and still prefer using something
| else (because it's garbage).
|
| So if you can make a chat app that can make Slack look garbage
| as a chat app, you don't need feature parity. Maybe adding an
| integration to external conf call services like Jitsi or Zoom
| can be enough for your potential customers, especially if they
| already pay for those.
| digging wrote:
| > because it's garbage
|
| I wish my company believed this.
| lolinder wrote:
| I use Slack huddles regularly even though my company _also_
| has Zoom and Google Meet, and would be ticked off if my
| company tried to replace Slack with something that was
| missing voice.
|
| Slack's huddles are about eliminating the friction for
| hopping on a voice call. There's no waiting time for Zoom to
| start, no camera check, no "join with computer audio". You
| can go from a synchronous text-based conversation to a voice
| call in two seconds flat, as soon as it becomes obvious
| that's what is needed. _That_ is the value proposition of
| Slack huddles, and external tools can 't replace that.
| holmesworcester wrote:
| (Quiet founder here.)
|
| I think both this point and OP's point can be true,
| depending on what the value is that people get from
| switching from Slack to a secure alternative. (And yes I've
| also been in teams that usually used Zoom or Meet but where
| the convenience of quick 1:1 calls in Slack was really
| nice!)
|
| If a team is sufficiently desperate (as some we've talked
| to are) for something with end-to-end encryption but
| specific advanced moderation features that Signal lacks,
| then using Zoom, Meet, Signal, or some other video calling
| solution is fine. Sure it will be annoying, but there's a
| clear benefit the organization gets in return.
|
| And yes, most teams do not get enough value from e2ee (or
| don't yet believe that they do) that giving up on the
| frictionlessness of a Slack huddle is worth it for them.
|
| If we find product-market fit with an enthusastic niche of
| teams that need security, we'll be able to grow from there
| and address their needs for video calls too. If we can't
| find some users who are passionate about the particular
| advantages of what we're offering and willing to trade some
| features and convenience for those advantages, we're toast
| anyway :) (But we think we've found some!)
| ilyt wrote:
| And you don't just need to check a checkbox but implement them
| well
|
| _stares at MS Teams_
|
| _vomits_
| pshirshov wrote:
| Recently I've tried to organise an IPFS source mirror for a linux
| distro.
|
| Surprisingly it is unsuitable for the purpose. My node had ~800
| peers, but only half of the nodes around the world were able to
| download anything even more than 24 hours after publishing.
|
| I don't know what's wrong but seemingly IPFS suffers from
| permanent brainsplit condition.
| holmesworcester wrote:
| (Quiet founder here) Quiet creates small, closed, private IPFS
| networks specific to each community, so it avoids a lot of the
| performance problems that plague the big global IPFS network,
| and is also a lot more private!
|
| We've run real tests with hundreds of nodes on Fargate and saw
| message delivery times grow to just a second or two. Plus
| there's a lot of room for optimization because right now
| OrbitDB doesn't even use the gossip network for broadcasting
| message data--it just broadcasts DAG heads and peers have to
| fetch message data in a second step!
|
| Making initial connections between peers is slow over Tor, and
| there are some known issues in Quiet right now when switching
| networks. But those aren't IPFS issues and once you're
| connected it's surprisingly fast.
|
| Also, while IPFS suffers from scaling issues, the underlying
| gossip network (which for us is the most important part) is
| currently powering the Ethereum beacon chain, which has a
| _massive_ number of peers (~800,000 IIRC?). So the gossip
| protocol library Quiet builds on is very robust. Future
| optimizations of Quiet will likely move the burden of moving
| data down the stack to the gossip protocol, and only use IPFS
| for "catch up" syncing and ensuring eventual consistency.
| quijoteuniv wrote:
| Why does this rely on Tor?
| Bu9818 wrote:
| Well, for one you can avoid messing with NAT traversal and port
| forwarding if you just use onion services.
|
| They list some more reasons here, mostly just for
| privacy/anonymity:
| https://github.com/TryQuiet/quiet/wiki/Quiet-FAQ#why-does-qu...
| _joel wrote:
| So run Tor if you need those, I'm still not getting why it
| needs to be a dependency persobnally.
| _joel wrote:
| Seems strange to me too, can't think of anything that would
| need it functionality wise that can't be done in less, let's
| say, problematic, dependencies.
|
| If you want to run on Tor, fine, just run Tor.
| huggingmouth wrote:
| What do you find so problematic with tor?
|
| I've been using another chat app that uses tor (briar) to
| chat with my family and the chatting app has been working
| flawlessly for us so far.
|
| Tor curcomvents the nonsensical restrictions that isps place
| on users and makes it very easy to build p2p applications. No
| need for stuff like nat stun turn. Just exchange public keys
| and go!
|
| If anything, I find it weird that other p2p chat apps don't
| use tor given how easy and reliable it makes the chatting UX.
| _joel wrote:
| I'd rather not participate in the network, have the network
| flow logs on my ISP and it's slow. You can run the app on
| top of Tor if you need it. Seems to be not just me that
| can't understand why it's needed and it's definitely turned
| me off as a potential user.
| upofadown wrote:
| Endpoint discoverability is important. You just need to come up
| with an hidden onion address and the network takes care or
| getting you connected to that address. That removes the need
| for a common server.
| wkat4242 wrote:
| Came here to ask this.. Embedding tor is a bit disingenious for
| adoption because it puts you in the same bucket as a lot of
| very abusive content. Not worth it IMO and the extreme privacy
| protection isn't really needed here.
| proprietario wrote:
| Interesting project! After diving into the codebase and looking
| around I found that iOS is not native... any plans on switching?
|
| otherwise are there some docs/papers on how this has to be
| implemented so I can start my own?
| hfuaiobfa wrote:
| What if I send some secret key using such a 'secure' app, and
| invoke some corporated app to sent large encrypted data? Thus the
| speed and security will both be granted.
| matt3210 wrote:
| Secure key exchange is a good idea, but your method hides the
| data, but not the source or destination
| comova wrote:
| incredible concept and really well built. so many hard problems
| being tackled here!
___________________________________________________________________
(page generated 2023-09-12 23:02 UTC)