Solarpunk technology

2346 readers

76 users here now

Technology for a Solar-Punk future.

Airships and hydroponic farms...

founded 2 years ago

MODERATORS

[email protected]

Building Autonomous, Off-Grid, Encrypted, and Solar Powered Communications Infrastructure (anarchosolarpunk.substack.com)

submitted 10 months ago by [email protected] to c/[email protected]

4 comments fedilink hide all child comments

top 4 comments

sorted by: hot top controversial new old

[–] [email protected] 7 points 9 months ago (1 children)

Interestingly, a Mexican cartel did something very similar for their comms network about 13 years ago (source)

Soldiers seized 167 antennas, more than 150 repeaters and thousands of cellphones and radios that operated on the system. Some of the remote antennas and relay stations were powered with solar panels.

[–] [email protected] 4 points 9 months ago

makes sense. but cartels have way more resources than your average solarpunkian group. the point is the same, to not depend on corporations with ties to government agencies. what worries me is that cartels using this could be a justification to ban the tech, or make illegal to belong to on such off-grid coms network.

[–] [email protected] 6 points 10 months ago

This was featured in a podcast episode recently too: https://www.iheart.com/podcast/105-it-could-happen-here-30717896/episode/how-to-make-your-own-encrypted-141367225/

[–] [email protected] 4 points 9 months ago* (last edited 9 months ago)

Wow, interesting. :)

I tried getting something like this a while ago.

I wrote a Java program that would use an USB serial adapter on Linux to talk to a radio modem (I tried a few varieties, mainly RFDesign and Chengdu EByte) and broadcast text messges. The program was roughly subdivided into a backend (repeater, this could be a Raspberry Pi) which didn't care about message content, and a front-end (user interface) which tried to decrypt every message, enabling messages without any recipient or sender ID.

The cipher was a one-time pad, and the clue to decryption was the unencrypted "pad index" field telling which index to take key material from (the program would take it from all of one's pads and try sequentially). If the message did decrypt, a checksum was revealed which matched the rest of the message, and this is how the program told the difference between success (show in the UI) and failure (discard, republish for others, don't retry decryption).

I also demonstrated (poorly) use to comrades in Finland during one Musta Pispala festival, but we didn't get far at all - buggy software and under-performing hardware are hard to demonstrate. But I did learn a lot and might retry some day. :)