omg. OMG. **OMG!!!**
Okay I know this sounds like nonsense but oh my god! Captp + handoffs on three *independent* peers over tor onion services, with everyone chatting over goblin-chat!
Each user has their own address on the p2p network! *No* central server!
This is HUGE!
If it isn't obvious why this is huge, and I guess my post doesn't make it obvious:
This is a completely peer to peer, end to end encrypted chat system written in *250 lines of code*. @spritelyproject's Goblins abstracts away the network/cryptography elements for you.
yeah sure. nice proof of work, but
1. its still much easier for me to explain my mother how to use my matrix server
2. clearnet is by design more reliable than tor (1 known-good tcp/ip connection vs 3+ unknown connections in sequence)
3. clearnet is by design more performant than tor (1 known-good tcp/ip connection vs 3+ unknown connections in sequence)
If we generalize the discussion at bit once more. Anyone who's willing to lower the barrier to entry to using, adopting, implementing and extending our #fediverse technology base for people from all walks in life and across our globe, is most welcome to join #SocialHub and participate in doing so.
There's tons of things to be done, between deepest tech levels and easy-to-use, unobtrusive experiences offered by fabulous apps :)
my mom taught me how to use an ibm-3270 text editor for fortran. "explain it to my mom" always consists of me explaining what's *new* since then, nothing more
but you have to understand that a threat model varies from person to person. Most people will happily settle for Signal or iMessage since those provide e2ee and that's probably good enough for their needs.
e2e encrypted p2p chat over tor probably fits a more serious threat model, and those who qualify for such a threat model will absolutely learn the technical skills to stay safe.
Not to mention that most technical hurdles can be abstracted and polished away for the end user, e.g. if you just consider e2ee as such, it is a complex technical mechanism that comes with caveats, but in many programs those are clear enough and the program polished enough for general consumption.
But polish and general consumption aren't the focus of a proof of concept, as you are surely aware.
On a separate note, your objections look orthogonal to the stated design goals in OP, so they don't look too relevant.
But I think the reason for more federation is rather that users don’t need to install anything. And creating something that can be installed cross-platform is pretty hard.
But at least the peer-to-peer part only needs to be solved once. If you have a programming language that solved the problem (similar to WebRTC, but maybe simpler: you only need the messages part), then peer-to-peer becomes much easier.
Question. Is TOR necessary for the p2p end to end encryption?
Can it also work using federated networking (while still encrypted either end to end or end to server)?
I feel like I have so many questions but it's still not clear for me so that I can't actually formulate any.
For starters, I presume the TOR thingy is something like a plugin for your system? Can we use any other implementation, say... I2P, or maybe a different p2p network using kademlia DHT, or whatever?
@yuki Hi! This is a good question and it's come up a bunch of times... it's a good one to answer!
No, Tor is not *required* for network communication in @spritelyproject. It just so happens that Tor Onion Services are an easy to use and set up p2p system that do NAT traversal, so they are the first one being demoed.
The "Machine Transport Communication Layer" is an abstracted interface, Tor is just one of many. You could use DNS + TLS or even carrier pigeons with encrypted microsd backpacks.
Ah, glad to know!
I've read a bit of the docs. Do you have any videos where you explain the actor model more thoroughly?
(I think this is where most people get confused because it sounds like arcane magic; it's a whole new paradigm - similar to what OOP or event-based programming were for old school programmers.)
I'd love to see a presentation where you explain your multi user chat from the API client viewpoint, and later you explain the basics of how you implement it over TOR or whatever.
@yuki @spritelyproject The video on https://spritelyproject.org/#goblins explains in some detail, and the FOSDEM one does too: https://share.tube/videos/watch/fd98bbdd-8c2e-4229-b0c7-e7b16937901a
I've been working on a lightweight UI framework. Vanilla JS MVC style in < 200 lines that does what React+Redux does, but without any npm and such.
I know you're working on the underlying infrastructure for the Oasis, so I've been trying to tackle the front end for web, in addition to a lot of my other use cases.
This is a sample PR where I added support for Reddit: http://git.tychi.me/tychi/roam/pulls/3
I'd imagine to interface with WASM in this paradigm, I'd call out similar to the `fetchPosts` function to getting reddit posts. Merge the latest chat messages into the state and it'll be available in the UI.
Embed the chat anyhere with like:
And that would render the UI from your screenshot.
I'm still in the early days, so documentation is lacking...
I guess that’s mostly because the people who build stuff in Freenet are interested in the technology, and few have the interest both in the tech and in making something enjoyable.
I hope that the mobile node will help with that: https://github.com/freenet-mobile/app
@smartyhall @cwebber if you run #Freenet and go on a site like http://localhost:8888/USK@4DQ15JpGlVGDdyXvQE3Egz7SLK2TzMAUmp~aptnwyt4,ljFASreV8AHaQhscfrNLuVyl3qksltgP9sndtLuUHB8,AQACAAE/stream-radiocc-freenet/3/
it takes around 5-10s to load the start of the stream — not much longer than it would take to open a youtube-page (I just checked: youtube takes 3 seconds until I can start the stream).
@smartyhall @cwebber I just measured it again on an empty Freenet node: Opening http://localhost:8888/USK@4DQ15JpGlVGDdyXvQE3Egz7SLK2TzMAUmp~aptnwyt4,ljFASreV8AHaQhscfrNLuVyl3qksltgP9sndtLuUHB8,AQACAAE/stream-radiocc-freenet/3/ takes 22s from clicking the link until you can listen to the audio-on-demand stream.
(note: not a live-stream, this is audio-on-demand (video also possible, but low quality for now). Livestreaming needs more testing to see its latencies and required upload bandwidth)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!