51–60 of 118 posts
Earlier quoted context omitted.
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
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!
Earlier quoted context omitted.
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.
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...
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.
> 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'…
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.
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…
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…
What are the problems with pubsub? Do they need to invent something not done before or it's just a skill shortage?
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.