nostr:npub16v82nr4xt62nlydtj0mtxr49r6enc5r0sl2f7cq2zwdw7q92j5gs8meqha also posted a note about mesh dev. Idk enough but figured you two have it in common.
Thanks for connecting us!
I'm educated on and have some experience with LoRa and LoRaWAN but I have only dabbled in Meshtastic so far.
I'm getting closer and closer to going in whole hog every day though.
1. That seems workable. I don't know all the details about the nostr protocol, but AFAIK follower lists are public, so stashing your follower list on your own server should allow the server to start checking those relays
2. Having a lot of connections on a mobile device isn't great, but with the above approach, you'd only need endpoints to connect to your own server (and some public relays to assist in finding new people to follow). Servers can handle thousands of concurrent connections, and there's no reason the connections have to remain constantly open to every relay.
I'd want to make sure that each of my clients has a complete copy of everything I'd need to spin up a new server. This would be things like DMs, following list, follower list, relay list, and so forth. I think that was assumed here, but I just wanted to point out that it's an important feature. Little servers go away all the time, so we want to make sure users have the confidence that people can recover when that happens.
Encryption can satisfy the desire for confidentiality, but it's important to be clear about what is being stored where and who has access. For example, "DMs are stored on your server, but the server can only see the sender and recipient, not the contents", and "list of people you follow is on your server and the server can see everyone on this list"
Yup. Everything worked fine for those two tests. Re-installing again now and will use different options during the initial setup (make sys-usb disposable)
To be clear, I think there's something here, but it either needs to have more to it, or have a clearly defined goal (e.g. "this is to provide a backup service, use other solutions for other problems")
Is setting up multiple accounts the only practical way of accomplishing this?
I know how to kinda filter views, but haven't found any way to control where the posts go on a single account. For example, I'd want want posts about programming go to one set of relays and posts about bible study go to a separate set of relays.
I like the idea of being able to easily run your own node, but this sounds like a UX nightmare unless there's also some way to better manage relays.
I'm imagining having to add a relay for every single person I want to follow and it sounds tedious.
The other concern is discoverability. If many people are only posting to their own relays, I'd never find them unless they have a webpage or something that I happened to stumble across. And if they're posting to public relays, why bother having a private mirror (which may be incomplete in terms of replies)?
I get that it could serve as a backup, and I appreciate that aspect. The other benefit would be that it'd be easier for small communities to form like I could set up a server for my local Makerspace or HAM club or whatever.
Bottom line: limited value unless combined with other changes
I'm also suspending disbelief that anyone would take a one-time payment to host something forever. That's a huge economic problem that would need to be addressed to go from "thought experiment" to "implementation"
Decided to re-test on my main desktop. Yup, still broken there. I haven't gone completely crazy... yet π€ͺ
Installing #QubesOS 4.2.0 again on my test machine. Whee!
Since I can no longer repro any problems when I manually created a USB qube, so now I'm going to try creating sys-usb during the initial setup. Maybe it's something being done in the initial setup?
We'll see! And I predict that I'll be re-installing this machine again later today.
Why go through all this effort?
1. I really care about Signet's software/hardware quality & compatibility
2. I want to be able to use Signet on my main desktop again!
Belay that. After removing and re-inserting the Signet, the udev rule worked properly and the #Signet works just fine on Fedora in #Qubes
Time to add the USB #qube back into the mix and see if I can repro the problem...
#GrowNostr
OK, finally some progress! Using the test machine, which is still set up with #Qubes 4.2 but without a USB qube: I made a Fedora-based qube, passed through one of the USB controllers, and it shows the Signet as "[unknown] [unknown]". It doesn't use the udev rule (or it does but the device doesn't match).
This is using the exact same kernel as my previous test with a Debian qube, where the Signet worked just fine.
So it seems to be related to Fedora, and unrelated to the kernel version/configuration.
No. #LoRa is the radio layer. It sends packets when you tell it to. No retries, no routing, no confirmation that anyone received the packet. It just shouts things into the void and listends for any transmissions.
#Meshtastic is a software package (and maybe a protocol?) that uses LoRa to form a mesh network. It handles things like retries, routing, figuring out what nodes are directly reachable versus indirectly reachable and so on.
An anology might be that LoRa is like UDP and Meshtastic is like VoIP.
You may also be interested in knowing about #LoRaWAN. That also runs on top of LoRa, but it is not a #mesh. It is designed for getting data from a LoRa device to a computer #network. There's a LoRaWAN gateway that translates between LoRa and IP networks. It also has multi-layer #encryption support built in. So the gateway can't see the contents of messages being passed around.
Sticking to the same anology, LoRaWAN would be more like TCP.
In contrast, Meshtastic isn't really designed to talk to computers. Embedded sysytems talk to one another and computers can talk to those embedded systems (e.g. via bluetooth). I don't know enough about the #cryptography in Meshtastic to speak about it intelligently.
#Signet #Saturday has now rolled into Signet #Sunday. I'd like to post an update, but I'm getting such positive results with #QubesOS and #TailsOS and #Debian, it's hard to describe where there is any problem.
It's a #heisenbug thus far. Hopefully I'll be able to open this box and collapse the state soon!
#GrowNostr
I sell them at cost if you pay in #bitcoin or a few dollars more if you pay in #fiat.
I'm working on ramping up sales so I can do bigger production runs.
Hope you sold when it was over 70K USD. Could buy it back now and have 10% more coin.
Hey #nostr, it's Saturday night, which means I'm playing with #cryptographic #hardware (#Signet). What kind of wild party are/were you at?
#GrowNostr #Cypherpunk
Looks like the #Meshtastic firmware supports a these weird like raspberry pi 2040 chips. That's attractive.
I was more looking for a library that I could run on a laptop or desktop and it would send/recieve packets via my LoStik.
I mean, I can reverse it from the wire format or read the code and create the documentation, but surely this has already been done, right?
OK, I got the persistence part sorted out. Not sure if it was enabling #UEFI, connecting the virtual disk via #USB instead of #SATA, removing the CD image, selecting a new option in grub (which didn't appear before enabling UEFI), or some combination of the above.
As for the #kernel config, that was OBE. Turns out #Signet worked just fine in #TailsOS on #Virtualbox with persistence enabled. And with persistence disabled. And directly on hardware with persistence disabled.
I swear, I used this exact same thumb drive and I never re-flashed it with a different version of #Tails and it was having issues. Same physical Signet device too!
#GrowNostr
I did not expect it to be so difficult to find the kernel config options for #TailsOS.
...or to run Tails in Virtualbox using the official instructions on how to do so...
#GrowNostr
#Signet #Saturday starts when I wake up. Not site
Sure when that'll be. I've stayed up pretty late tonight... er this morning? I don't even know.
