/tech/ - Technology

I used to use Briar for a while. it's pretty neat. for those who don't know, its main selling point is that it is metadata resistant. its main downside when I used it was battery usage, because it had to stay connected to Tor. message delivery is also an issue, because both users have to be online. in a group chat this is easier, but it's still necessary for a critical mass of people to be online for messages to percolate

Boomp

Whenever one of these decentralized peer-to-peer web3 projects comes up, the most important question to ask is "How does it do peer discovery?" because this is a pretty difficult problem to solve without a central server. I looked into it and apparently Briar just piggybacks on the Tor network and uses that for peer discovery, and Tor itself uses a set of directory servers for peer discovery, so it's not exactly fully decentralized. Also I'm not so sure about how the Tor people feel about projects like this; the network is already slow enough as it is without everyone and their brother using Tor as the backend for their Web3 projects especially when all their software is set up to run Tor in client mode by default and not relay mode, thereby using the Tor network's resources and giving nothing back.

Honestly, if all these web3 developers really want P2P they should learn how to do actual P2P, not cheat by using someone else's open-source volunteer-driven P2P network. That's script kiddie shit.

P2P is hard, peer discovery is hard, NAT traversal is hard. To design decentralized peer-to-peer networks requires a thorough knowledge of networking and computer science, doing a lot of research about the history of P2P and understanding how all the P2P networks have dealt with problems like peer discovery, learning about P2P network topology and unstructured vs structured P2P networks, reading the huge amount of academic papers on the subject and designing and running simulations of your network to conduct experiments and test different theories, etc.

There's a reason why the guys who developed Kazaa went on to develop Skype and become billionaires - they figured out how to solve some really difficult problems like NAT traversal and developing an efficient method of peer discovery using "supernodes" with the FastTrack/Kazaa protocol and then they applied those same principles to P2P audio/video communication when they wrote Skype. They actually did the work and built their networks from the ground up, they weren't skids piggybacking on someone else's network.

>>31630
I think exit nodes are rather the bottleneck of the network, but even then people are encouraged to route as much traffic as possible through tor and i always get decent speeds when browsing websites or streaming <360p video.
>>31636
What do you think about the DHT approach, which usually requires central servers for bootstrapping?

>>31637
>What do you think about the DHT approach, which usually requires central servers for bootstrapping?

Honestly I don't know that much about how cryptography or how DHTs work, I just know they are used by networks like Bittorrent and ED2K for peer discovery, but regardless of the methodology you always need an initial bootstrap node to access any P2P network, so full decentralization is not really possible with the unicast nature of the internet; it's not exactly feasible for clients to portscan the entire ipv4 address space every time they want to connect to the network, and scanning the entire ipv6 space would be impossible, so there has to be some point of initial contact with a trusted central authority.

>>31639
What if, and I assume this is already the case somewhat idk, we decentralized the authority? Check this server, or that one, or that one…
Decentralized centralization.

>>31647
>Decentralized centralization.

That's just called federated servers, which is what P2P networks generally resort to for bootstrapping peer discovery - a federated list of mutually-trusted nodes/dns servers/etc. hardcoded into every client so that they have some initial point of contact with the network. That's how Bitcoin and Tor connect to the network for the first time, it's how Limewire and Kazaa and other P2P filesharing clients worked, even Bittorrent clients rely on a hardcoded list of trusted bootstrapping nodes for connecting to the DHT network.

I've thought about ways to get around this problem, like coming up with some kind of parasitic network signaling mechanism clients can exploit to discover each other by (mis)using various public-facing internet services such as cloud storage or comment sections or even dns caching on public dns resolvers. A clever hacker might be able to come up with some pretty neat ways of doing that and there's a few academic papers about this sort of thing.

>>31651
Can you link/post the paper? Please, I have thought about this sometimes too

I might be dumb but I never understand what's the point of messaging apps. How is that better than social media with DMs?

And if you want P2P messaging, why not just self host ? Then it doesn't need the P2P stuff. It's facultatively P2P because you are hosting your own shit.

Also doesn't IRC work over TOR perfectly?

> DHT

DHT doesn't REALLY require bootstrapping. But it does not solve the NAT problem. And it's the opposite of private since you share your IP with 4 million strangers. The point of DHT is to find out your friend's IP address so you can then connect to them with whatever program you want to run. This makes more sense for connecting strangers than people who already know each other. That's why it's used for bittorrent.

> bootstrapping

if you have a routing table stored somewhere you don't need dedicated bootstrap servers. But you can only get a routing table by being in the DHT. So it's chicken and egg. But in theory you could email someone your routing database with no problem. There is no need for centralization of any kind in the DHT. Except maybe for NAT.

for example here are some hosts that are active in the DHT right now:

< ECE54BCB833B0B9022B07AA2D69B4E8CB14866F5 10004 23.158.56.119
< E0522E6E216904D5C0EFF4D5D52367908DBD9336 26979 60.234.206.33
< E924E1545BBB046E6D7F8D8898F7088027A14C72 20167 72.21.17.24
< EF29870CFDC0C4358C96A42BFBC950C079B4417D 28016 178.162.174.171
< E43BA79725D946662E9571D0DB73F7DCEB6112EC 1292 95.27.16.235
< F2DCA7D6E5F30B3A4DCBC0D949031EC2EE704AE3 6881 50.114.206.65
< F24147894F35F0AE93969A5D7822F48D7079C717 6881 103.21.166.88
< F58A6C000D566AFF9BFD7555CD16FB74CDEFD89E 52609 41.99.131.102
< DEBD3A45137016C7660E9A3C070F62A0EBCBE320 24059 172.111.38.128
< D11338EBB55BB230F82A476944D90852C76FB5DB 6882 142.215.167.167
< D9327E3B725B666D793E436B58D21B97C8C7C56B 51413 71.201.216.204
< D9B4FC8A6C9342EB3137F49E946DC15EA38C3E92 38722 188.242.144.109
< D0DECC0D488500CE829AA9C54A9B4631E93BC6AF 10244 194.9.79.138
< DACB2A774949798B4D1F9195DA61E5186F675040 7964 220.120.75.19
< D68112BA8F3814A9F86E4FFDEA3590A5F2F8BADF 6881 83.253.82.170


As you can see it is 100% public info, and yes organizations monitor it

>>31651
>coming up with some kind of parasitic network signaling mechanism clients can exploit to discover each other by (mis)using various public-facing internet services
That avenue of research seems intriguing. I've thought about implementing a messageboard in js on top of a static-page before, which is theoretically possibly with WebRTC, but doesn't allow natively for any discovery mechanism to my knowledge. Connecting people without centralized rendezvous-points and beyond exchanging addresses with your friends, phonebook-style, appears to be a hard problem in the current network.

>>31652
>Can you link/post the paper? Please, I have thought about this sometimes too

I can't find the specific whitepaper I remember reading before, it might be locked behind paywalls now, but the concept is known as a "DNS dead drop" or a "dead drop resolver" and it's often used for covert C&C in botnet and malware networks. DNS is like the ancient legacy backbone that the Internet is forever stuck with and it's a UDP-based protocol with no state or error checking of any kind and there's a lot of nefarious stuff you can do with it. Here is a PDF I found which goes over the general vulnerabilities of DNS as a protocol and some of the ways it can be misused for this sort of thing:

https://blackhat.com/presentations/bh-europe-05/BH_EU_05-Kaminsky.pdf

>>31668
>I might be dumb but I never understand what's the point of messaging apps. How is that better than social media with DMs?

The client-server model works for sending text messages and sharing pictures and videos and stuff like that, but it doesn't work for live video/audio streaming. It is not possible for Discord's servers to handle millions of simultaneous live video/audio streams between all of the Discord users of the world; for video/audio calling, Discord merely functions as a signaling server and it uses WebRTC to create a direct peer-to-peer connections between users for the actual video/audio stream.

>And if you want P2P messaging, why not just self host ?

How does anyone find you? How do they connect to you? Are you behind a NAT? Can you forward ports on your router? Do you have a static IP address or a domain name? Is your device a computer on a network that you control or is it a locked-down smartphone that doesn't let you host anything?

>if you have a routing table stored somewhere you don't need dedicated bootstrap servers

Yeah, if you have the routing table, i.e. if you have connected to the network before (and recently) and have an up-to-date list of active peers on a constantly churning network.

>for example here are some hosts that are active in the DHT right now:

The key phrase there is "right now" - check back in a week or so and see if any of those IP addresses are still active in the DHT or if they are even still pingable.

>>31671
>Connecting people without centralized rendezvous-points and beyond exchanging addresses with your friends, phonebook-style, appears to be a hard problem in the current network.

It's more like an impossible problem, even the parasitic storage solution doesn't really solve the problem; you're still relying on centralized servers, only now it's without the consent of the centralized servers, so theoretically you could use some very well-known public central server like Google's 8.8.8.8 DNS server and devise some way to store small amounts of arbitrary data there and use it as a covert signaling server to facilitate P2P peer discovery between a bunch of random clients. Of course this introduces a whole share of new problems - it would be much more complicated and inefficient and unreliable at finding peers compared to a simple hardcoded list of known trusted bootstrap servers, and Google or whoever is running the service you are abusing would probably figure out how to identify and block your traffic eventually if they figure out what's going on.

See also: https://en.wikipedia.org/wiki/Domain_generation_algorithm

Keep in mind, security experts struggled to combat this sort of thing long before the days of LLMs; imagine what could be done nowadays, where you could algorithmically generate domains that are completely impossible to distinguish from legitimate domains.

>>31671
>I've thought about implementing a messageboard in js on top of a static-page before, which is theoretically possibly with WebRTC, but doesn't allow natively for any discovery mechanism to my knowledge. Connecting people without centralized rendezvous-points and beyond exchanging addresses with your friends, phonebook-style, appears to be a hard problem in the current network.

You can use a pre decided fake infohash as a shared password and exploit the bittorrent DHT like this board does. uvl4xhrtupoygytfikwttev5pl2n2lyfajbedy5b7lbwtupndd4lh6yd.onion/board/mu
The program will look like normal bittorrent peer finding activity.

>>31673
>Domain_generation_algorithm

You can easily do this too, for example sha256(infohash+month+year).

>>31674
>sha256(infohash+month+year).
Careful, SHA2 is vulnerable to length extension attacks. It's better to use SHA3 or Blake3 for this purpose.