[HN Gopher] Berty: Peer-to-peer messaging app that works with or...
___________________________________________________________________
Berty: Peer-to-peer messaging app that works with or without
internet access
Author : sirffuzzylogik
Score : 213 points
Date : 2021-01-27 10:10 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| MayeulC wrote:
| 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?)
| LockAndLol wrote:
| 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?
| andycrawford wrote:
| Awesome. Can't wait to see the difference between berty and our
| own in-app messaging system at tabtimize.
| akavel wrote:
| How does that compare to Secure Scuttlebutt?
| robert_foss wrote:
| SSB doesn't do encryption. Yes, you read that right. Messages
| are only signed.
| 3np wrote:
| That's not true.
|
| https://scuttlebot.io/apis/scuttlebot/private.html
|
| If you're strictly talking about the core protocol, yes,
| applications and protocols with other encryption mechanisms
| can be used instead.
| georgyo wrote:
| 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.
| sirffuzzylogik wrote:
| 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.
| Shared404 wrote:
| 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.
| sirffuzzylogik wrote:
| 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?
| jlokier wrote:
| 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
| sirffuzzylogik wrote:
| Thank you, I contacted dang, sorry again for the issue.
| dang wrote:
| Ok, we've removed Show HN from the title above. Honest
| mistakes are never a problem, so no worries!
| 3np wrote:
| 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.
| hnlmorg wrote:
| 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.
| chovybizzass wrote:
| I applied for the qa role. you guys can stop applying.
| exabrial wrote:
| 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!
| kangaroozach wrote:
| Also for txt messages other BLE to another RF device such as
| GoTenna is pretty cool!
| avianlyric wrote:
| 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.
| exabrial wrote:
| 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
| hodapp wrote:
| 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.
| jonas_kgomo wrote:
| ELIF: what does it mean without internet access? Does this mean
| without wifi I will be able to send messages?
| Jorropo wrote:
| We are using Bluetooth.
| cuu508 wrote:
| 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?
| freeCandy wrote:
| 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
| Snitch-Thursday wrote:
| > 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
|
| [1]https://github.com/Nutomic/ensichat
| kangaroozach wrote:
| Like GoTenna Mesh?
| Deivuh wrote:
| In the description it says "No internet connection required
| (uses the BLE technology and mDNS)"
| donpark wrote:
| From Github page: they use BLE and mDNS.
| jedahan wrote:
| > 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.
| sschueller wrote:
| 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...
| durpkingOP wrote:
| why don't you remove it yourself /choosingbeggars
| intotheabyss wrote:
| Nice, pure cryptography at its finest.
| algorithm314 wrote:
| 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.
| peter_d_sherman wrote:
| 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!
| swiley wrote:
| 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?
| robotmay wrote:
| 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).
| de4np wrote:
| 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
| hmhrex wrote:
| This hollr idea is cool. I feel like just having your own
| instance of this would be enough as a product.
| [deleted]
| jFriedensreich wrote:
| 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.
| intricatedetail wrote:
| What are the problems with pubsub? Do they need to invent
| something not done before or it's just a skill shortage?
| jFriedensreich wrote:
| 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.
| Vmody2 wrote:
| Pretty cool to see non-crypto projects being built using IPFS.
| zelphirkalt wrote:
| 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.
| LockAndLol wrote:
| If you know which repo it is, open an issue. It is indeed
| unexpected for them to be using AMP
| KoftaBob wrote:
| 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.
| tleb_ wrote:
| 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
| upofadown wrote:
| 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.
| throwaway94737 wrote:
| Metadata.
| sandworm101 wrote:
| 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.
| kangaroozach wrote:
| 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?
| ajconway wrote:
| 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.
| deckard1 wrote:
| > 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.
| zrm wrote:
| > 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.
| maverick74 wrote:
| there is also Briar ( briarproject.org )
|
| ;)
| robotmay wrote:
| 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.
| lucideer wrote:
| 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).
| robotmay wrote:
| 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.
| kangaroozach wrote:
| 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?
| lucideer wrote:
| > _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.
| dreit1 wrote:
| 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
| Jorropo wrote:
| The BLE driver will be iOS, Android and linux cross compatible.
___________________________________________________________________
(page generated 2021-01-27 23:01 UTC)