published a draft of the rationale behind Singularity, a soon-to-be-developed decentralized social networking system. looking for advice or interested collaborators re: distributed systems, cryptography, unique challenges for marginalized people, and whatever else we might need help with.
LB: hi, i'm working on this project too!
in case you can't see, it's a decentralized social networking thingy that @byte and i are working on. here's a little rationale writeup: https://trashbyte.io/singularity/
we're looking for help re: cryptography, distributed networking systems, online-social challenges for marginalized groups, and anything else a burgeoning social thingy could need. so feel free to reach out to either of us if that sounds like you!
@typhlosion @byte nice to read some opinions on a similar idea I had. While dabbling a bit with OpenFlow SDN, I had one problem: I needed a representation of a computer, to know that I'm reaching the same host twice and beyond.
Computers can have dual-ethernet, wifi, bluetooth, 5G modems and other outgoing interfaces that all use Internet Protocol. Look at your phone and wonder what happens if you used Bluteooth PAN, WiFi and 4G all at the same time. In the end, I needed a mesh protocol.
[+]
@typhlosion @byte
[+]
When designing the data and application layers, I reached other conclusions.
Instead of splitting "Identity" "Networking" and "Content" into different provider boxes, I thought like "everything is a file" and settled at "everything is a claim". A base "NULL claim" that points towards some hard-coded behavior (like pypy, it's Rpy built-ins and cpython reimplementation as py scripts) would provide the required bootstrapping.
[+]
@typhlosion @byte
[+]
(forgot to add last message: all base claims are publicly readable, but claims can contain encrypted claims in its message)
Instead of propagating changes, some devices would prefer fetching changes and entering a low-power mode. Battery-powered devices like phones, for example.
Disallowing writing custom user-patchable server code might end up like ZeroNet, but there's the "application handles interoperability" caveat from Linked Open Data to also avoid. [+]
@typhlosion @byte [+] If everything was already precalculated in a middleware-provided materialized view, the data conversion problem would be solved.
About patching and running code, that's a complex matter. I hope that representing code in an intermediate ontological representation allows me to run stuff together despite programming languages. The hard part will be tracking conflicting contributions (such as deep refactorings) together.
[+]
@typhlosion @byte
[+]
About UI, I'd avoid web browser engines as hard as I can. DIY IoT projects that relies on a ESP32 wouldn't be able to use them. Wouldn't use especially after doing accessibility checks for web pages. But GUIs are needed to exist.
All that said, I hope that the project becomes easier to build applications than playing an API deployment provider such as Heroku or Render, and looks better than electron, so people have an actual place to move out from the commercial web.
@typhlosion @byte
[+]
After working with an oldschool internet enthusiast, I could finally understand why university professors compared internet with telephone system: IP is basically a telephone system with a fixed size. It carries over a lot of flaws, which includes all the means for arbitrarities from any part (censorship included). I can imagine some ways to aglutinate computers, but I'm still not sure if it would scale well and still fit within the constraints of an arduino.
[+]