Hacker News new | past | comments | ask | show | jobs | submit login
Berty: Peer-to-peer messaging app that works with or without internet access (github.com/berty)
386 points by mpsq 10 months ago | hide | past | favorite | 113 comments

> Berty does not and will not need blockchain in its protocol

This is one of the first things I look for around decentralized communications+apps these days, and I am very happy to see no blockchain here.

> The main concept of the Berty Protocol is the "group", a virtual place where multiple devices can share messages and metadata using OrbitDB, which itself relies on IPFS.

Doesn't IPFS rely on blockchain?

I believe there's some work being done to use cryptocurrency micro payments as a layer on top of IPFS to incentivize data storage.

edit; Filecoin, https://docs.filecoin.io/about-filecoin/ipfs-and-filecoin/#d...

no, it uses distributed hashtables to find stuff.

Not at all.

The people that make it are developing a blockchain product that uses IPFS, but that is totally separate.

Not for basic features. There is discussion about using smart contracts via ethereum to enable some eCommerce/dynamic kind of flows in a distributed way, but there are non-blockchain alternatives being talked about too.

A fascinating idea, I wish you a lot of luck in this endeavor!

If I were going to go this route, that is, to engineer a network not dependent on the Internet -- I'd first go down to the most fundamental principle of WiFi, Bluetooth, ZigBee, EDGE, EVDO, LTE, etc. -- and that most fundamental principal is RADIO.

From there, I'd ask the question -- how can any device which implements one or more of the wireless protocols that we all know and love: (https://en.wikipedia.org/wiki/Comparison_of_wireless_data_st...) be converted back to raw radio?

If it can be done, use that and design upwards.

If it can't be done, then use the lowest abstraction level (above raw radio) possible that can be used for the device in question...

That's the comm side of things.

The "next job up" is to figure out the logistics of user adoption, getting these radio devices to communicate, what bitrates to use, what access patterns to use, how do you get data over longer stretches (if there's no user/node to hop off), etc., etc.

But, quite the technical challenge!

Of course, you can "cheat" -- and use pre-made protocols/software/drivers -- which gets you the highest amount of abstraction (but the least amount of control).

SDR -- Software Defined Radio -- would seem to be a good middle ground between these two areas of abstraction...

I'd almost argue that if someone were to make the simplest of all SDR's that could turn ordinary WiFi cards and devices into SDR, and couple that with a store-and-forward network like FidoNet or Bitnet (if anyone remembers those!), then they'd be in business!

Anyway, it's a very interesting and challenging project!

I wish you the best of luck in this endeavor!

> I'd almost argue that if someone were to make the simplest of all SDR's that could turn ordinary WiFi cards and devices into SDR

SDR became wildly popular (well, relatively, amongst geeks) when someone worked out a ~$10 usb dtv tuner could be used easily as an SDR receiver. There are very few (but not zero) rules around recieving radio signals.

Once you start transmitting though, things get way moire complicated very quickly. Some of those radio protocols you listed (Bluetooth/WiFi/ZigBee) typically use "ISM" radio bands, where the rules are less stringent (but there are still rules), some of the protocols you mention (EDGE/EVDO/LTE) will very quickly get you found/shutdown/fined if you start transmitting on them. Telco's pay millions for the licenses to those bands, and strongly protect their exclusive use of them.

If you "just use" your wifi/bluetooth radios as they were designed, you'll be complying with all the regulations (including things like ensuring you abide by geographically different available channels, 2.4GHz channel 14 and sometime 13 and 12 are not available depending on where in the world you are: https://en.wikipedia.org/wiki/List_of_WLAN_channels#2.4_GHz_... )

If you start screwing around at a low enough level to be controlling the radios without the higher level drivers - you become responsible for all the global regulatory shitstorms you might bump into. While that would be a fun thing to play with (and I say this as someone who's used a USB VGA dongle as an "SDR Transmitter" in ways that are _totally_ not legal where I live), it's not really a sensible path to go down if your goal is widely usable decentralised non-internet connected messaging.

First of all, a lot of good info, so I appreciate that!

I'm not going down this route right now (too many other priorities), but I like to think strategically about this subject, as I do about many others.

>"SDR became wildly popular (well, relatively, amongst geeks) when someone worked out a ~$10 usb dtv tuner could be used easily as an SDR receiver."

Strangely, I never heard about this, but I'd be interested to learn more; links/references?

>"Once you start transmitting though, things get way more complicated very quickly. Some of those radio protocols you listed (Bluetooth/WiFi/ZigBee) typically use "ISM" radio bands, where the rules are less stringent (but there are still rules), some of the protocols you mention (EDGE/EVDO/LTE) will very quickly get you found/shutdown/fined if you start transmitting on them."

I don't question that certain types of radio transmissions may offend one or more people; and/or one or more "powers-that-be"...

But, let's clearly, and I mean super-clearly understand the exact specifics of what those are, because you see, there is room, there is a lot of room for experimentation -- outside of those parameters.

You see, what someone can or can't do, radiowise, is largely determined by a matrix of different factors -- think of this as a giant Excel spreadsheet -- but with multiple factors determining whether something in radio can be done or can't.

So let's talk about some of those factors.

One of them is the distance to other people. If I live in a cornfield in Nebraska, and my next door neighbor is 35 miles away, unless my radio transmission goes for more than 35 miles, it probably isn't going to piss off anyone.

Conversely, if I live in a tightly packed city, like New York where my next door neighboor lives in an apartment 20 feet away -- then 20 feet might be the largest practical distance that my radio transmission might be able to go before it pisses someone off.

So that's one aspect of this 'matrix'.

Another aspect is, what country do I live in?

Because different countries have different rules.

On the ocean, at 200+ nautical miles from the coast of the nearest country, or on the North Pole, or South Pole, or in Outer Space (if I can get there) -- I can probably get away with a longer broadcast -- without pissing anyone off.

But those are only some of the parameters of this matrix.

Another parameter is frequency, another parameter is power relative to that frequency, another parameter is the directionality of the transmission (for example, am I using a directional radio beam formed by a cone-shaped transmitter, and how does that beam spread out, and how far does it go, and who is in its path?).

Then, there are what are called "Caduceus Coils" -- they're a special coil/broadcast antenna -- which if it designed correctly, acts like the "laser beam" equivalent, except for rf; the radio transmission.

If that tightly focused radio beam is about the size of a dime, and travels directly, over air, to its target location (which is some other guy agreeing beforehand to receive that transmission, to become a "node" on the network"), then that radio transmission will not interfere wtih any other radios (receiving or transmitting) outside of that laser-thin line; in other words, it should interfere with no-one, it should not piss any person or power-that-be, off...

You see, to quote William Shakespeare's "Hamlet":

"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."

I don't mean to offend you by saying that; but you see, there's always another angle; another possibility that may have gone unthought-of (until someone points it out).

In other words, "Don't assume", or phrased another way "Assume Nothing" (Mike Abrash).

Yes, people would probably get offended if you connected with a cell phone tower on one of their frequencies using one of their protocols without their permission -- but I am not proposing that that be done!

Instead, I'm saying -- look at the possibilities.

The multi-page spreadsheet/matrix of factors must be created and then consulted to see where the empty spaces are (empty space = opportunity for experimentation!).

Anything that is not prohibited -- is, and must be by default, permitted! (You know, that old Grace Hopper "permission vs. forgiveness" debate!).

>"you'll be complying with all the regulations"

My question is this: Do the regulators even understand what they are regulating?

I understand both Law and Radio technology.

I could do their job; they probably couldn't do mine...

>"it's not really a sensible path to go down if your goal is widely usable decentralised non-internet connected messaging."

Yes, but my goal isn't to go down this path -- it's to think about what to do about greater shitstorms (greater amounts of shit hitting the fan than it does already) if and when they happen!

I hate to dumb it down to this level, but proverbially speaking, in this matter "I'm the good guys" (er, guy, singular, as the case may be... <g>)...

> You see, to quote William Shakespeare's "Hamlet":

>"There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."

Sorry, but a can’t help but think from your wordsalad here that you understand barely more about regulatory aspects of radio bandwidth use than Shakespeare did... I can’t even work out where to start to guide you down a path where your “Understanding of both Law and Radio” might start to intersect with reality in 2021 society. So I’m not even going to try.

One hint I will throw you about SDR - use the keyword “RTL SDR”, you’ll find many simple and amazing projects using USB tv tuner sticks available for ~$10 repurposed as Software Defined Radio receivers. These days they are used for everything from global flight tracking like Flightradar24 up to some amazing things like passive radar tracking planes via reflections from powerful radio station transmitters.

Did I not say "I don't mean to offend you by saying that" in my message?


Two Questions:

1) What is the first principle of Law? Why does it exist?

2) What is the first principle of Radio? How does it exist?


Also, I might suggest that labeling others, while highly effective at shutting down debate (this technique is used by TV news anchors -- label opponents, then offer a quick quip as to what the majority in society would disagree with most with the label previously given, then feel good about having done so), is also equal-and-oppositely highly damaging to one's own continuing education, the education which, if it were continued with an open mind and without such actions -- would make a person highly (and I mean highly) effective over time, such that whatever they would seek in life, they would an uncannily high probability to attain...

That is the function of angles and possibilities, angles and possibilities not explored, angles and possibilities which are shut off if/when someone tries to shut down "opponents", by whatever methods (labeling, smears, painting them with a broad brush, etc., etc.)

But, for the sake of not provoking a debate, you want me to say that "I'm an idiot"?

Fine, "I'm an idiot."

You want me to say that I understand barely more about regulatory aspects of radio bandwidth use than Shakespeare did?

Fine, "I understand barely more about regulatory aspects of radio bandwidth use than Shakespeare did."

But here's the thing.

You see, I can say those things because I'm not afraid of the repercussions of saying those things (there are none for me. <g>)

I don't believe them for an instant, however.

Two Questions:

1) What is the first principle of Law? Why does it exist?

2) What is the first principle of Radio? How does it exist?


Everything that the FCC (and its counterparts in foreign countries) regulate -- are waves that are Hertzian in nature.

These types of waves follow the Inverse-square Law:(https://en.wikipedia.org/wiki/Inverse-square_law), that is, they drop off inversely proportional to the square of distance.

It's a good thing that they do, too, because otherwise everyone's radio transmitter of whatever type (cell phone, garage door opener, TV remote, Wi-Fi, etc.), would interfere with everyone else's -- and this doesn't happen.

Nature, via the Inverse-square Law -- prevents this for the most part...

But, while Hertzian waves are used by most of the devices we know and love, in Physics, there are also Non-Hertzian waves (scalar, transverse, longitudinal, etc.).

These require special equipment and engineering to both create and detect (compare to Gravitational Waves, LIGO, etc.), and they might be highly directional in nature (that is, if you're not in a very tight path, you cannot detect them, but that's a good thing, because it also means that they don't interfere with all of the radio devices that we know and love!)

You see, there is nothing in Physics that (with the right engineering) that prevents the transmission or reception of information on non-Hertzian waves, on any number of mediums.

Sunlight, the earth's magnetic field, radiation from space, and many other mediums -- could in theory be used to send and receive information... even Gravity itself could be, in theory, if it is a wave, and if it were properly understood...

Also, Quantum Communication -- the idea that you take a crystal (or some other medium), and split it in half, and (again, with the right engineering) now can communicate over large distances without an apparent medium between them -- this idea is Non-Hertzian in nature.

ESP, if it exists -- is Non-Hertzian in nature.

Non-Hertzian communications are the future (basically it's Star Trek technology).

Hertzian (which the FCC and its counterparts in foreign countries regulate and can regulate) is the present-day -- and the past.

In other words, a prediction: In the future -- there will be a disruption of Internet scale in Communications -- when Non-Hertzian communications technologies become dominant...

Also, with respect to Law -- the root of all Law (all human Law) is human agreement -- which is also the root of all man-made contracts.

Congress (or any other governing body) cannot change Natural Law -- that is, no act of human agreement will change the nature of Gravity, nor any of the Laws (pure laws, natural laws) that govern the physical universe...

Or perhaps as Star Trek's Scotty would so eloquently say:

"Ye cannot change the laws of physics!" <g>

I don't really know how to read your comment. All the wireless protocol that we use are actually "raw" radio whatever that means. You can use them to do P2P communication if you want to as demonstrated by this protocol.

The way you physically transport data can be safely decoupled from how you will encode and how you want your protocol to work. It makes thinking about the different layers easier and allow them to evolve independantly. Nothing prevents you from building an IP network using ham radio as a transport. The OSI model wasn't developed as a purely theorical concept. It does solve a practical problem.

>"I don't really know how to read your comment. All the wireless protocol that we use are actually "raw" radio whatever that means."

Sometimes the most profound of truths, the most elegant of truths, are so simple, so as to be overlooked and/or written off by people.

In this case, you see, if "everything is turtles" all the way up, then at the base layer, the turtle all the way at the bottom, the turtle who rests on no other turtle, well that turtle is "radio".

Let's change the topic and talk about cars for a second.

You have drivers, people who can drive a car, that is, people like you and me.

But then you have a subsection of these people, who are mechanics, who can fix most typical problems that a car might have, but there are limits to their capabilities; they couldn't make a car more aerodynamic, or reengineer a gas car to be an electric one, etc.

Then you have, as a subsection of Mechanics, Car Design Engineers (all Car Designers are in effect Mechanics also, because their knowledge is a superset of the mechanic's knowledge).

The Car Design Engineer can do "miraculous" things that an ordinary Mechanic cannot -- he or she could make a gas car electric, an electric one gas, could design for higher MPG, could swap out systems, etc., etc.

The Mechanic works at a lower level of abstraction than the car driver does, and so, can do many things that an ordinary car driver cannot, but the Car Design Engineer works at a still lower level of abstraction than the Mechanic -- and thus he or she can do "miraculous" things that the Mechanic cannot...

"It's all raw radio" -- is the simple, elegant, most profound truth at the bottom of the stack of turtles (compare to the concept of common denominators in Mathematics), it's the lowest-level abstraction, it's the abstraction level that, should we work from it upwards (rather than pre-built protocols, drivers and stacks) downwards, we'd find that we can do things that we otherwise couldn't, if we were forced to work within the constraints of all of those pre-determined systems.

Finally, the Internet itself -- the Internet itself -- IS A SERIES OF ABSTRACTIONS -- a series of "Turtles on top of other turtles".

The Internet itself...

Meditate on that one for a second... I did, and the implications of that meditation were profound!

Why shouldn't someone commit to learning about all of those levels of abstraction, and gaining the corresponding power of amazing engineering (aka, "abstraction working") abilities -- should that knowledge be gained?

I love the way you thought about solving the problem Peter. You clearly have a lot of experience peeling back the layers of technology. I wish more people left thought out comments like yours.

Let me know if you're interested in brining to life your suggestion :)

Hi Armani,

I greatly appreciate your kind and uplifting comment!

(Although, and I'd say this to everyone else, I also appreciate highly critical comments -- because they challege me to think, to really think, to refine exactly where I stand on a position in words, and to fix that position if it contains any inconsistencies... On a side note, I should write that down in my philosophies in the future -- good comments (like yours!) are good, because they're positive and uplifting, but "bad comments are also good" (paradoxically!), because they force you, they challenge you to really think...)

>"Let me know if you're interested in brining to life your suggestion :)"

Well, I greatly appreciate it, but I don't have the time for it... I'm merely adding some ideas to the discussion.

You know, add some "lively" ideas -- to an already "lively" discussion! <g>

Anyway, thanks again for the kind words!

Not sure if there is any benefit to stripping back to raw radio. You can almost always build on top of other protocols to get a pipe that you can then build your protocol on.

I'd love someone with knowledge-experience with radio to chime into the feasibility of such a system, what the constraints and potential legality of it could be. I'd imagine a mesh network like this could be most useful during natural disasters that disable wired/powered communications, maybe for wartime anti-tyranny - however radio waves could be blocked/tracked and targeted afaik, so maybe not foolproof for that use case.

There's a few groups working on this in various forms.

Two ones I've been paying close attention to are; https://www.meshtastic.org/ http://disaster.radio/

Legality-wise can get complicated, there's only certain frequencies you're legally allowed to run encryption on, and then there's wrinkles around hardware and transmission power.

Only[1] height above terrain matters for VHF radio and up. Unless you pay the big bucks for power and space on a tower or the top of some building, it doesn't matter how impressive your modulation gain is or how powerful your transmitter is or how high of gain your antenna is. Your software is barely relevant.

The thing that makes the cellphone mesh network work is that they spend lots of money getting their antennas up high above the terrain and getting power to them.

[1] Yes, there's sporadic e tranmission but it's just that, sporadic. And yes, there's troposcatter but that literally requires kilowatts and highly directional large antennas.

See this "Roundup of Secure Messengers with Off-The-Grid Capabilities (Distributed/Mesh Messengers)":


I’ve been playing with Meshtastic and some ESP32s recently. Works like a charm, but no security other than “channels” and currently no iOS app. The Python API has a ton of features, and it seems like this could tie in nicely.

Ummm, I've not touched any of my Meshtastic devices for a few months, but I'm _reasonably_ certain everything other than the "default" channel is encrypted.

First ht on Google seems to agree: https://www.meshtastic.org/software/crypto.html

WiFi supports peer to peer stuff just fine. Before the internet was pervasive me and my friends would play starcraft/minecraft over ad-hoc wifi networks with link local addresses.

Cell phone OSes automatically disconnect from these of course, there's no way to connect to the ad/telemetry services so what good would it be anyway?

> Cell phone OSes automatically disconnect from these of course

Not all phone OSes. None of my iOS devices disconnect from local WiFi because they don't have Internet connectivity. I do this this all the time with several devices I have that broadcast their own WiFi for remote control connectivity.

> WiFi supports peer to peer stuff just fine

Not to mention that there is huge mesh networks around the world deployed by private persons, all using WiFi over KMs of distance.

Any examples? Very interesting.

- NYC Mesh - US - https://www.nycmesh.net/

- Freifunk - Germany - https://freifunk.net/

- Guifi - Spain - https://guifi.net/en

Guifi is probably the largest of those, with 36.924 online nodes, most in Spain but some in other parts of the world. If my memory serves me correctly, there is peering working/in progress between Freifunk and Guifi as well.

One example is Freifunk in Germany. There is also a large network in Spain, but I forget what it is called.

There is also this: https://news.ycombinator.com/item?id=25412367 which was recently discussed on HN.

More people need to get into or at least learn about ham radio for this reason. Modern telecommunications is a gross abstraction, and is taken for granted.

"if someone were to make the simplest of all SDR's that could turn ordinary WiFi cards and devices into SDR"

I dont think you said what you think you said.

I really love every effort in this space and especially if making good use of ipfs, but to give an idea about how far this is from the maturity of lets say signal: the more mature parts of ipfs are just starting to become mainstream in the last couple of months. But Berty relies on the very experimantal database orbitdb that relies on the pretty experimental pubsub feature of ipfs that is to my knowledge nowhere near generally usable and scalable. I would consider berty and orbitdb as well as other projects relying on ipfs pubsub all very exciting "future" projects that are just waiting on ipfs to solve the technical challenges and as soon as the ipfs team is ready they will be ready too in a relatively short amount of time. But when that will be is hard to tell, all i know is that pubsub is experimental since early 2017 and my yearly tryouts so far always come to the conclusion that it cannot be widely used yet but will be key to a lot of ipfs applications and could lead to a breakthough for many usecases for ipfs.

What are the problems with pubsub? Do they need to invent something not done before or it's just a skill shortage?

Its a super complex problem to solve, it has been done in some way many times before but not with the exact constraints and tradeoffs that fit well to the rest of the ipfs architecture and that will work on a global scale with unreliable connections and delivery times in the area of ~ a second. Maybe some ipfs dev reads this and can chime in but as far as i understand they are not even really sure about what the correct algorithm for message distribution should be to build on.

Looks interesting but from what I can tell currently isn't available on app stores to immediately try out. It does at least have a nice logo which is ultimately enough to make me try something :p

I'd like to see the slew of new messengers coming out also address one of the few areas keeping people on Facebook: group event planning. There's lots of places to chat, but not many alternatives for sharing and planning events with a wider group of people. Briar seems to offer blog and forum concepts, which is interesting, but everything seems to be lacking in the "event" aspect and that's unfortunately a bit of a sticking point for a lot of Facebook users (it's primarily what I use it for, still).

I've been thinking the same, so i built https://hollr.at. it's a PWA and probably alpha/beta quality at this point, being a side project. It works pretty good for me at least and others not familiar with it can join and attend without an account which seems to be appreciated. There is no stickiness or discovery to it though.

Apart from meetup.com I'd say that eventbrite.com looks pretty good. There is also https://mobilizon.org/en/ which seems to be federated, so you have the option to self host

This hollr idea is cool. I feel like just having your own instance of this would be enough as a product.

This brings up a question I still haven't gotten a clear answer to: why isn't Signal peer-to-peer like this?

What is it about p2p that made it not doable, rather than Signal's current setup where every message goes through a centralized server before reaching the recipient?

Would appreciate any insight.

There are practical problems. Does no internet also mean no network connection? Getting two devices to talk to each other without a network is not straightforward. Bluetooth can do it but has range limitations. Wifi can do it to, but there you have to get into very hardware-specific wizardry to move packets between devices without a network router. The target devices, cellphones, are designed to provide network access, to login to a backbone of other devices, not to generate and manage the network themselves.

Then there is the issue of encryption. Verifying keys is tricky without a common network. How does one revoke or renew a key? It is possible but complicated. Not something that a messaging app would normally attempt.

> Wifi can do it to, but there you have to get into very hardware-specific wizardry

Android is supposed to support the standard for this called WiFi direct - https://en.wikipedia.org/wiki/Wi-Fi_Direct#Mobile_devices. I've not seen much about it actually being used, though.

Apple has its own proprietary thing that it uses for Airdrop, which unfortunately is not cross-compatible.

Thoughts on GeTenna? What about an open source encrypted protocol that uses an RF device like GoTenna on specific longer range frequencies? Anything like that exist?


> What is it about p2p that made it not doable

Well, everything?

Nothing about mobile devices is suited for p2p. Mobile devices are the exact opposite of what you want for p2p to function smoothly. The devices are always going offline, they move around and acquire new IP addresses, they can't run things in the background without significant battery drain. And probably most important: NAT and routing issues. This isn't the '90s where two computers can just freely talk across the internet on any port they want to.

At the very minimum you would need a centralized discovery server. At that point you may as well scrap the whole idea anyway.

Not really. A DHTs can perform this without a centralized discovery service. Bit torrent for instance uses this, and clients can trade peers without being on the DHT.

Additionally there's so many bittorrent clients that there's millions of machines in the DHT and even a brute force search of IPv4 is't going to take long to find one of the millions, which will happily give you dozens of other peers.

So sure many clients include a bootstrap server for the DHT, but that's needed once and you can skip that if you are willing scan a few 1000 hosts for a client.

I've pondered writing a DHT based client for signal like functionality (sync messages, async messages, and resistance to traffic analysis), I don't see any technical blockers. I get why signal is centralized and does have some attractive features that would be hard to match with a p2p setup. In particular quick startups, low message latency, and battery/network efficiency. With that said I think a p2p e2e chat client is quite feasible.

What would make it MUCH more feasible is people started buying wallwart arm systems (more common years ago), or raspberry Pis and ran a p2p client as a service so that clients in the home could leverage the service for email, chat, file transfers, etc.

I'm very intrigued by these "wallwart arm systems" that you mentioned. Where can I read up on this?

None are current AFAIK. I do think that the downsides of P2P could be largely offset by assuming a raspberry Pi or equivalent small system to offset the battery, bandwidth, and CPU penalties that are so hard to justify on Mobile.

So they are of historical interest only, but if you want to did up the history I'll give you some search terms. Marvell had a $99 reference platform called the SheevaPlug CloudEngine had a Pogoplug, CTera had a CloudPLug, Seagate DockStar, GuruPlug, DreamPlug, PylonPlug, sipJack, GeNiJack, etc. etc. etc.

They all had a GHz or so CPU, GigE, 512MB ram, etc.

> Nothing about mobile devices is suited for p2p. Mobile devices are the exact opposite of what you want for p2p to function smoothly.

That's true for their (usually) CGNATed cellular data connections and NATed home wifi connections. But if you were happy to consider a solution where "p2p" meant "peers within bluetooth and wifi range of each other can store/forward messages in a mesh" then mobile devices are _exactly_ the piece of hardware you'd want. Add in some IPFS store/forward from opportunistically internet connected devices to allow message passing between disconnected local meshes, and you should build a really interesting (low bandwidth very high potential latency) messaging system.

(Note: this "disconnected meshes with opportunistic internet connection" is pretty much what things like LoRaWAN and Meshtastic can do, but using specialised LoRa radio hardware instead of the built in capabilities of every smartphone on the planet.)

> Nothing about mobile devices is suited for p2p

Nothing about "traditional" p2p is suited for mobile devices.

Software has to adapt. Mobile phones would be excellent platforms if it wasn't for software limitations.

Having GSM, GPS, WiFi and Bluetooth, while being carried around, make phones the best candidates for location-aware sneakernet-style p2p.

> At the very minimum you would need a centralized discovery server.

That's not necessarily true. You could use a DHT. Or have decentralized discovery servers, i.e. your username is user@example.com and then example.com is contacted to coordinate direct communication with user. Or for local networks, use multicast service discovery to find local users.

Because the problem they've chosen to solve is "secure reliable e2e encrypted messaging via the internet". (or something very similar to that)

It's a big enough problem on its own. Tacking "p2p" on as well makes it a different thing, which is not what Signal are doing.

I want my Signal messages to arrive at my friends Signal clients, even if that's later after they've recharged their dead phone. I don't want my Signal messages to vanish if I (or a friend) is on a WiFi network where p2p is blocked. There's a serious need for a centralised server for Signals goals to be achieved, so they have one. The fundamental design then means the added benefit of _also_ implementing p2p where possible is small, while the effort/cost is high. Of course that didn't build that.

Forward secrecy normally requires a handshake where both endpoints are online. Signal is obsessively forward secret. The Signal Protocol's claim to fame is that it can do offline messaging while still providing forward secrecy. It very much requires a server to store the required cryptographic state to do so.

I guess the restriction could be considered some sort of downside that comes with protocol complexity.

I have this to-watch talk marked as Signal & centralization, so it might provide part of the answer: https://www.youtube.com/watch?v=Nj3YFprqAr8

The issue with pure p2p is that devices are not always online. Mobile devices usually forbid (or at least highly discourage) executing code in background which doesn’t help either.


Take a cryptokey routing-based network such as https://yggdrasil-network.github.io, cjdns, hyperboria or (I think) TOR.

The crypto-addresses be used as contact information, and users can message each other any way they want: e-mail, netcat, a dedicated application, etc. End-to-end encrypted, no WAN connection needed on mesh networks.

Now, the hard parts are:

- Persistence

- Async communication when one of the hosts is offline.

- Multiple devices pertaining to the same user, with key revocation, etc.

The firsts are why I'm excited for things such as Matrix. I'm not sure about the last (and is there really a problem in the first place?)

Looks good and I'm excited where this leads but please remove items such as "https://www.shakebugs.com/" from the android build [1]. If I want privacy I don't want some bug reporting tool tracking me.

I also hope you will add this to fdroid although it will be hard with Reactive Native. A native android app would be preferred.

[1] https://github.com/berty/berty/blob/master/js/android/app/sr...

In the readme it says:

> We want to contribute to the world of free, secure communication without fear of censorship and surveillance.

But their website does not work without allowing ampproject? Or so I thought! Apparently after 5s or so it does load content and displays it. Still kind of weird for them to go with amp stuff. Unfitting their goals.

If you know which repo it is, open an issue. It is indeed unexpected for them to be using AMP

Jami is a very good p2p messenger - teleconferencing app. There are still some bugs, but it is usable. The next version is probably going to have group chats.

So I guess if it goes phone to phone by Bluetooth/IR/WiFi AP, then home to home by a meshnet-alexa size/style device. The next part is the cross country/continent. Maybe HAM(bad bandwidth) or some nice billionaire has free/unmonitored satellites ha to replace the undersea cables.

Random side note: I was wondering how you could use space to store information. Like you use the stars as the canvas then change the incoming light as the write... Doesn't make sense would get destroyed but yeah.

It is super nice seeing Berty on the HN front page. I know the founder, who has done many things before among which initiating the Paris P2P meetup (https://p2p.paris), so I've been hearing about it for over a year now. Hopefully the app will be available to the public soon!

Pretty cool to see non-crypto projects being built using IPFS.

An E2EE messaging app is not a crypto project?

When will the cross platform driver be available for offline communcation. As it stands looks using the Berty will be restricted by Android to Android or iOS to iOS communication

Also what are the typical distant constraints in an offline environment

The BLE driver will be iOS, Android and linux cross compatible.

How does that compare to Secure Scuttlebutt?

A big difference is that Secure Scuttlebutt uses a blockchain (the “log”). An app keeps one's own entire log + the entire log of every contact within the “hops circle” (hops=1: friends, hops=2: friends + friends-of-friends, …).

SSB doesn't do encryption. Yes, you read that right. Messages are only signed.

That's not true.


If you're strictly talking about the core protocol, yes, applications and protocols with other encryption mechanisms can be used instead.

I know people like harking on about phone number or email requirements, but how am I supposed to find my friends? Do I have to send them a message over Signal to tell them the name I picked on another app?

Something like that.

That's the big reason Moxie chose to use phone numbers. Piggyback off the pre existing social network from people's contact lists.

It's great for viral uptake, even if it's not as privacy preserving as a (way way) less usable "random identifier I chose" messenger like, say, Wickr. It's not a surprise that the two big names in all the discussion about WhatApp's Privacy Policy update and mass exodus were Telegram and Signal, with of which use phone numbers as social network kickstarters - instead of "I can choose any username I like but then nobody can find me and anybody could impersonate me" messengers like Wickr.

Not just that though, it makes it much more expensive to say create 1M signal clients to try to spam users, deceiver users, or create a DoS. Phone numbers/sims create a limit on the feasible number of accounts an individual (or even a company) could control.

It would be cool if there was a BLE -> inter webs gateway that could be ran on something like a rpi or other very low cost common hardware.

LOVE the concept of this project though. Starred and keeping an eye on it!

6LoWPAN has a variant that can use Bluetooth Low Energy (rather than 802.15.4) to carry IPv6. See https://openwrt.org/docs/guide-user/hardware/bluetooth/bluet... for instance.

Isn’t that just WiFi with extra steps?

BLE gets most of its energy efficiency from aggressively turning the radios off when they’re not in use. Wifi can do the same thing, and protocols like Thread are pushing in that direction.

The big issue with a BLE to interwebs gateway is that you means you need to handle routing etc. Which starts to erode the benefits of using BLE in the first place.

I'm more talking about being able to exchange messages across continents without offering somebody full TCP/IP access to your network. Your point is valid though

Also for txt messages other BLE to another RF device such as GoTenna is pretty cool!

there is also Briar ( briarproject.org )


Are there any public forums on Briar? I'd kinda like to try out that aspect of it (and the blogs) but it suffers somewhat from a blank canvas when first setting it up :D

Edit: Looking closer I see contacts have to share forums, which is a shame. Would be nice to be able to join directly from a code.

The only p2p messenger I've used that hasn't suffered too badly from "blank canvas" is Manyverse.

It's technically not a dedicated messenger (more like a p2p encrypted Facebook equivalent, with a p2p FBMessenger equivalent built-in as a side feature), but that aspect just makes it a lot easier to find people to chat with.

It's unfortunately not quite as stable/performant as Briar though (yet).

One thing about Manyverse and ssb that scared me off after a while is that all of the content you view gets downloaded on your device / phone, and then subsequently passed on to others. So if you subscribe to some sort of public group and someone posts some disgusting / illegal shit you're now downloading it onto your device and in the worst case share it further against your will. Has there been any progress towards eliminating that issue, or am I just too paranoid about it?

I did have a bit of a play with Manyverse (and with SSB itself in the past) and it looks interesting. The lack of syncing between desktop and mobile SSB accounts is a bit of a pain which I think will hinder adoption until they come up with a solution to that.

I do worry that a lot of these newer messengers and networks are operating on a memory of what social networking was like in 2010. Quite a few at least handle photos, but few, if any, handle videos, and none that I've seen have pinched Facebook's events, which are a pretty key feature for me in convincing people to swap.

> lack of syncing between desktop and mobile SSB accounts is a bit of a pain

Yeah that's something they're actively trying to figure out, but it's tricky given their "Signal-/WhatsApp-esque" single-device architecture.

I think some of the work Matrix are doing on federated key exchange could be of some help though; my general understanding is that multidevice, single-account encrypted communication is hard.

What if they use IPFS for encrypted larger file size messages and treat the main message as they would an on-chain message that references the ipfs CID?

What on Earth us Facebook Events? During a pandemic lockdown?

Ha ha.

Events was the only feature keeping me on Facebook pre-lockdown. I only realised months after the pandemic started that I'd forgotten to login to Facebook since.

Would still be nice to have a non-Facebook platform to use for this if irl events ever resume.

I applied for the qa role. you guys can stop applying.

Is there a comparison anywhere between this, Briar, Session and (P2P-)Matrix? I love that there's so much innovation in this space recently, but also really hope that any of them can really break into the mainstream.

...aaand I just looked and it's in their FAQ. Just didn't see it before.

Store-and-forward messaging can be implemented on top of many networks: Internet, local wifi, bluetooth, usb drives, LoRa, and many more.

Why bundling together UI, message routing and network backends?

Why can't we go back to layered software design?

It's not immediately apparent what platforms this is for. In the releases there's at least Linux binaries available.

ok, i spent 5 minutes and i still have no info how it actually communicates? wifi, wifi radio, bluetooth, ultrasonic chirps, modulated light, all of the above?

i would have thought frst thing to say, it tends toi make me suspicious, but they look like good guys, just lacking some transparency at this stage.

How does it differ from Briar?

Nice, pure cryptography at its finest.

Like Briar?

The poster of this "Show HN" seems to have zero involvement with the development of berty.

I've been eagerly awaiting the release of berty for a few months now, but they have not made public the app yet. They have a closed beta, for a few months. And their build process for the android app is complex.

While berty is extremely interesting tech, I don't think it's quite ready to be on Hacker News yet.

OP here, as you said and to confirm, I am not involved with the development of Berty in any way.

My understanding is also that Berty is not fully production ready yet, however I have been following the project for a while and they seem to be going into the right direction. Other HNers might also be interested and who knows, the project might grow faster with more people involved.

I believe the reason the GP brought that up is that Show HN's are typically used to show something that you've made yourself.

This is an interesting topic though so a standard submission would work well.

Thanks for explaining, I thought "Show HN" was for any app/project to be demonstrated, not necessarily affiliated with the poster. I just (re)read the rules and I am sorry for this mistake, maybe @dang can amend the title?

This may help: https://news.ycombinator.com/item?id=22777953

>> @dang

> The correct way to contact dang on issues like this is to write email to hn@ycombinator.com

Thank you, I contacted dang, sorry again for the issue.

Ok, we've removed Show HN from the title above. Honest mistakes are never a problem, so no worries!

Early-stage prototypes and weekend hacks show up from time to time - it shouldn't be expected that "Show HN"s are production-ready.

Who knows, someone might just jump in and contribute.

The OPs point is that "Show HN" is for something the submitter is involved in. Otherwise it's just a normal submission. In this instance the title shouldn't be prefixed with "Show HN:". Aside from that, there's nothing wrong with the submission.

ELIF: what does it mean without internet access? Does this mean without wifi I will be able to send messages?

From Github page: they use BLE and mDNS.

In the description it says “No internet connection required (uses the BLE technology and mDNS)”

We are using Bluetooth.

What happens when Alice wants to send a message to Bob, but they are not in Bluetooth range of each other?

Can a Birdy client with internet access serve as a gateway to other Birdy clients without internet access?

> Can a Birdy client with internet access serve as a gateway to other Birdy clients without internet access?

That's so far unclear to me as well. I will say, if they can crib some code or at least hints on how that might be done (provided they even want to support that feature), there was an old app out there called EnsiChat[1] that IIRC had internet relays running on servers, but was P2P-first.

So: if Alice could see Bob directly via P2P, they could chat. Or, if Alice could see Bob indirectly, they could still chat.

No idea if it supported meshing P2P connections to get Alice's message to Bob via Alice -> internet relay -> Frank -> Dmitry -> Bob


It doesn't seem to be fully reliant on BLE.

From the docs [1]:

> It is possible to fully use the Berty Protocol without ever accessing the Internet: create an account, add contacts to it, join conversations and send messages as long as there are Berty users within a Bluetooth range.

[1] https://berty.tech/docs/protocol/#direct-transport

Like GoTenna Mesh?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact