First they came for our financial privacy. People like the #EFF spoke out against it.
Now they're coming for our #cloud #privacy.
https://www.lawfaremedia.org/article/know-your-customer-is-coming-for-the-cloud-the-stakes-are-high
How much #surveillance and Know Your Customer (KYC) regulations are too much? #kyc
Are you talking about this software? https://meshtastic.org/docs/software/linux-native/
If so, what LoRa radio hardware do you use on Linux?
This is a super sad story about the American education syatem: https://www.okdoomer.io/im-a-professor-heres-why-im-walking-away-from-my-tenure/
Remember: fossil fuel companies want people to focus on what **uses** #energy so we don't talk about the supply side.
They benefit from #environmentalists spending time and energy bickering with one another about whether AI uses too much #electricity, whether to support more #nuclear plants, whether we should mine more #lithium to have grid scale #batteries, and so forth.
That doesn't mean we can't talk about these things, but be #mindful where you spend your energy.
#FossilFuels #PowerDynamics #EatTheRich
It's a really tough call, but I think this might be the sweet spot. Maybe half time to bring in enough dough to get by and the other half for family/personal projects?
They called their product ReplyGuy
https://503junk.house/@rose/112349387538932488
You can't make this stuff up!
Cheating on college exams. π€£
Random thought: call lightning wallets a "wallet" and on-chain wallets a "safe". A "vault" could be reserved for muti-sig on-chain wallets.
It'd be a familiar way to explain the concept of not having a ton of money in your wallet and not being able to buy something with your wallet if your money is in the safe.
In my mind these would be separate devices, maybe a phone an a laptop/desktop/hardware wallet to make rhe distinction more clear, but with a good user interface, I think it could be conveyed on a single device too.
I also like the idea of hiding all of these details away as long as there's a familiar way to explain why sometimes the fees are a penny and other times the fees are a dollar for a similar transaction.
#bitcoin #ux
Spotted in the United States: a $0.10 fee for using a credit card at a vending machine. For context, a 20 fl oz soda is $2.50, which makes this a 4% fee.

If bitcoin want to compete here, it needs to be at least as cheap, fast, and easy.
Yeah, this code is huge and the structure is not immediately apparent. The comments and debug prints look really good (FIXMEs not withstandimg π€£)
I looked into #meshtastic on a desktop again and I'm sad to report that it looks like it's really immature (at best). The TL;DR is that the best case scenario has the software working with a single #LoRa USB adapter and that looks like it's far from certain.
If you're interested, I show my work below.
There's a #Linux native app, which you'd think would be the end of this thread, but unfortunately not. Almost everything here is about emulating Meshtastic traffic, not transmitting and receiving with a real #radio https://meshtastic.org/docs/software/linux-native/
There's a single sentence saying it can use hardware, but no more info there. Tine to start digging. π§
They link to https://github.com/geeksville/framework-portduino which says it works with "the Pine64 Lora USB dongle". Maybe that uses the same hardware as the LoStik? Let's see.
Well, the only USB LoRa device that pine64 seems to sell is the Pinedio: https://pine64.com/product/pinedio-usb-lora-adapter/
That page says "The Pine64 USB LoRa Adapter for PineDio ecosystem, suitable for SBC application." So, in other words, not suitable a desktop operating system. But it gets worse. That page goes on to give a big red warning "Software for receiving and sending LoRa messages via this adapter already exists, but at the time of release no SBC operating systems have implemented support for it."
Not compatible with the LoStik. Like, at all.
What does all this mean? It means that Meshtastic on a desktop is likely not ready for developers to tinker with.
What about tinkerers writing their own code that implements the meshtastic protocol in a way that will work with and USB LoRa device? I'm afraid that's not currently easy either. This is because Meshtasic is not a protocol, it's a piece of software. The documentation has great diagrams https://meshtastic.org/docs/introduction/ but no detailed specification.
What this means is that for someone to write desktop software which is compatible, they first have to read through the Meshtastic source code and try to figure out what the code does and why. Since there's no protocol, these internals could change at any time.
I leave you with this though. There is hope. It's likely that the core LoRa part is fairly simple and the WiFi/Bluetooth parts don't need implemented on a desktop app. So it should be something a single developer could do in ~20 hours/week for a couple months. Much less if they are a Meshtastic developer who is already familiar with the code base.
The same is true for documenting the software and writing the specification.
So it can be awesome. It's just not there yet and we just need a volunteer to take it on. β
There is another option: use the #desktop with a standard #Meshtastic device and connect over BT/WiFi. This doesn't solve any of the aforementioned problems such as "there is no documented protocol", but it would allow one to get up and running much much more quickly.
So, depending on your goals, that might work for you.
I looked into #meshtastic on a desktop again and I'm sad to report that it looks like it's really immature (at best). The TL;DR is that the best case scenario has the software working with a single #LoRa USB adapter and that looks like it's far from certain.
If you're interested, I show my work below.
There's a #Linux native app, which you'd think would be the end of this thread, but unfortunately not. Almost everything here is about emulating Meshtastic traffic, not transmitting and receiving with a real #radio https://meshtastic.org/docs/software/linux-native/
There's a single sentence saying it can use hardware, but no more info there. Tine to start digging. π§
They link to https://github.com/geeksville/framework-portduino which says it works with "the Pine64 Lora USB dongle". Maybe that uses the same hardware as the LoStik? Let's see.
Well, the only USB LoRa device that pine64 seems to sell is the Pinedio: https://pine64.com/product/pinedio-usb-lora-adapter/
That page says "The Pine64 USB LoRa Adapter for PineDio ecosystem, suitable for SBC application." So, in other words, not suitable a desktop operating system. But it gets worse. That page goes on to give a big red warning "Software for receiving and sending LoRa messages via this adapter already exists, but at the time of release no SBC operating systems have implemented support for it."
Not compatible with the LoStik. Like, at all.
What does all this mean? It means that Meshtastic on a desktop is likely not ready for developers to tinker with.
What about tinkerers writing their own code that implements the meshtastic protocol in a way that will work with and USB LoRa device? I'm afraid that's not currently easy either. This is because Meshtasic is not a protocol, it's a piece of software. The documentation has great diagrams https://meshtastic.org/docs/introduction/ but no detailed specification.
What this means is that for someone to write desktop software which is compatible, they first have to read through the Meshtastic source code and try to figure out what the code does and why. Since there's no protocol, these internals could change at any time.
I leave you with this though. There is hope. It's likely that the core LoRa part is fairly simple and the WiFi/Bluetooth parts don't need implemented on a desktop app. So it should be something a single developer could do in ~20 hours/week for a couple months. Much less if they are a Meshtastic developer who is already familiar with the code base.
The same is true for documenting the software and writing the specification.
So it can be awesome. It's just not there yet and we just need a volunteer to take it on. β
And before anyone tells me "That sounds like a great plan, you should do that, Dr. Hax!"
1. You're right, but
2. I have too many other projects going on
I am a full time gardener/homemaker plus I have Signet, [REDACTED], [REDACTED], three volunteer jobs, and one not-sure-if-paid-or-if-volunteer gig.
While I want to also do this meshtastic development, it means other things fall on the floor (by force and at random if I don't choose something to set down).
I looked into #meshtastic on a desktop again and I'm sad to report that it looks like it's really immature (at best). The TL;DR is that the best case scenario has the software working with a single #LoRa USB adapter and that looks like it's far from certain.
If you're interested, I show my work below.
There's a #Linux native app, which you'd think would be the end of this thread, but unfortunately not. Almost everything here is about emulating Meshtastic traffic, not transmitting and receiving with a real #radio https://meshtastic.org/docs/software/linux-native/
There's a single sentence saying it can use hardware, but no more info there. Tine to start digging. π§
They link to https://github.com/geeksville/framework-portduino which says it works with "the Pine64 Lora USB dongle". Maybe that uses the same hardware as the LoStik? Let's see.
Well, the only USB LoRa device that pine64 seems to sell is the Pinedio: https://pine64.com/product/pinedio-usb-lora-adapter/
That page says "The Pine64 USB LoRa Adapter for PineDio ecosystem, suitable for SBC application." So, in other words, not suitable a desktop operating system. But it gets worse. That page goes on to give a big red warning "Software for receiving and sending LoRa messages via this adapter already exists, but at the time of release no SBC operating systems have implemented support for it."
Not compatible with the LoStik. Like, at all.
What does all this mean? It means that Meshtastic on a desktop is likely not ready for developers to tinker with.
What about tinkerers writing their own code that implements the meshtastic protocol in a way that will work with and USB LoRa device? I'm afraid that's not currently easy either. This is because Meshtasic is not a protocol, it's a piece of software. The documentation has great diagrams https://meshtastic.org/docs/introduction/ but no detailed specification.
What this means is that for someone to write desktop software which is compatible, they first have to read through the Meshtastic source code and try to figure out what the code does and why. Since there's no protocol, these internals could change at any time.
I leave you with this though. There is hope. It's likely that the core LoRa part is fairly simple and the WiFi/Bluetooth parts don't need implemented on a desktop app. So it should be something a single developer could do in ~20 hours/week for a couple months. Much less if they are a Meshtastic developer who is already familiar with the code base.
The same is true for documenting the software and writing the specification.
So it can be awesome. It's just not there yet and we just need a volunteer to take it on. β
TIL how crappy #passkeys are. As the author points out, #FIDO2 didn't have these problems. It was a beacon of hope until #Apple and #Google got involved.
https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shattered-dream/
The TL;DR is that requiring resident keys were a mistake.
#cryptography #security #cyber #cybersecurity
It looks very minimaliatic. I like it!
Not sure if this was rhetorical, but if not, it's because they payment wemt directly from the payer to the payee.
Using that same logic:
if you asked someone to pick up a pack of smokes at the store when they're out, they might be a money transmitter.
if you order something from uber eats, I believe they would not be the case. As I understand it, you pay uber and uber pays the business, so in each transaction is a direct payment.
As for the people who are suggesting ISPs would qualify as a money transmitter... the only logic I can think of for exempting them would be under "common carrier" rules.
I don't agree that these regulations are reasonable, just trying to explain where they're coming from. I am not your lawyer.
If you want a TLS tunnel, I can vouch for stunnel being awesome.
So vintage. Check out those old logos. And the price is pretty vintage too! π

Would you like any suggestions on the topic? I'd be happy to try to help you avoid breaking system packages.
