Hacker Newsnew | past | comments | ask | show | jobs | submit | 405nm's commentslogin

you can’t think of a single thing that could be better about the hardware and software experience of phones?

not one?


I never said that. I said I don't want to see change for change's sake.

If you can come up with a better experience and it's a worthwhile change that materially improves the product, I will take it of course.

On the software side iOS introduces new useful features for sure, I don't deny that. They also took a nice simple flat UI and glass-ified it in a really dumb way. And the OS is so bloated that I lose 10-15% of my storage to packages and installation files (seriously go look up how much of your phone's storage is used by "System files").

But on the hardware side these days they're just fiddling with the camera and moving the buttons around, and that's not something I want to have to care about when I upgrade.

This is of course all subjective, I'm sharing my view here, not implying that I speak for the world.


it isn’t


that map on rmap.world is only showing nodes that run dicoverable=yes in their configurations or something like that.

based upon the announce stream coming through my local node, i am seeing around 14k unique identities advertising over 21k unique application endpoints (destinations) over the course of the past month or so that i’ve been tracking it.


It seems odd that such a tiny proportion would run `discoverable=yes`. Any idea why that is? It makes me question the numbers.


because the protocol is transport agnostic, there are a lot of interfaces to the public reticulum net that you can access over TCP, I2P, or yggdrasil.

https://github.com/markqvist/Reticulum/wiki/Community-Node-L...

takes away some of the fun of imagining the SHTF-all-corporate-infrastructure-is-gone scenario i guess but i think that for realistic mesh networking applications it’s cool to build out many infrastructure types and enjoy the fact that the mesh will reconfigure itself realtime across a variety of scenarios.


don’t forget that although it already works fine on lora, it’s a protocol that’s transport channel agnostic, and is gonna do great with other transports (halow, optical, wifi, whatever) when people finally start realizing that lora is never going to be able to keep up with bandwidth/speed requirements of anything much beyond simple text messaging.

although, i’ve already done real time voice calls over 1 hop of reticulum lora on and it works pretty ok.

edit - community wiki with getting started instructions is here:

https://reticulum.miraheze.org/wiki/Welcome


> simple text messaging

Also great for position tracking, sensor data or motion detection etc.


This for days. Cheap sensors that anyone can churn out for days and deploy to anywhere for weeks to years. No longer do I have to know if the garden beds need to be watered.


For that specific use case, if you already have a component out there, couldn't you instead have it trigger water at some % water saturation?


i like it a lot, being agnostic to communication channel sets it apart from the lora only meshes. it’s cool to be able to use a mesh device to communicate with people who are both on and off the mainline internet seamlessly.

and there’s some cool stuff happening on nomadnet as well l

oh yeah and there’s a voice chat protocol that works over lora, too


> communicate with people who are both on and off the mainline internet seamlessly.

I feel like trying to do that at the protocol level might be the wrong level of abstraction. Different fabrics have very different properties. Seems like the app is the more appropriate level for seamlessly communicating via different fabrics.

Like if I try to send a video to someone but they're currently only visible to me via lora the software probably shouldn't try to push a huge blob of data over that particular medium. But I probably do want the option of sending and receiving large blobs in general, just restricted to high bandwidth connections.


it’s a bummer, but according to folks in the matrix chat, he’s still developing and in touch with some of the community devs.


meshtastic is chat and lora only. its protocol is super inefficient and unreliable, and only can handle a maximum of 7 hops across the mesh.


Give a try to Meshcore, their design has proven to be reliable in realworld use.


all users need to be running the reticulum network stack to be able to send, receive, and route packets.

reticulum itself describes the network stack (like tcp/ip) and it has its own protocols like LXMF for messaging and LXST for streaming. applications can be built on top of these protocols.

it’s different than IP, instead of addresses, each node has an identity that’s a cryptographic key pair that you send messages to, the routing happens in the background regardless of network topology or diversity of link types.

you CAN send reticulum packets over a TCP/IP adapter and thus across the normal Internet (there are a lot of testnet and community nodes that are accessed this way), but the protocol also seamlessly bridges over any interface (lora, bluetooth, HAM radio, etc) that is attached to the node.

so like, there could be a message sent over lora to a base station that relays it to another server through the internet, then that server sends it out over a ham radio link to another computer somewhere else, etc.

all the message sender has to know is the pubkey of the node they want to talk to, and the network figures out how to establish a link.

128 hops maximum.

the prerolled binaries of the aforementioned software include the network stack and easy enough presets to find content from other nodes and people to talk to.


it hit version 1.0.0 this summer and it works!

to get started easily, check out meshchat:

https://github.com/liamcottle/reticulum-meshchat

or sideband on android:

https://github.com/markqvist/Sideband

you can already send photos and voice chat over lora, and when lora runs out of bandwidth or if there’s no link, the protocol can seamlessly go over any other link type.


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

Search: