I can haz ephemeral messaging channel extension on dat protocol and I can haz seamless authentication proof of concept. Little win.
:awesome:
I can haz ephemeral messaging channel extension on dat protocol and I can haz seamless authentication proof of concept. Little win.
:awesome:
Scratch the last #hypha update. Just realised I don’t need reproducible local writers in order to implement the flow I want and, in fact, that I was basically replacing an indentifier with a statistically insignificant risk of collision with on that could very easily collide.
Fun times.
Oh well, you code and learn :)
#Hypha Multiwriter-2 spike progress: Got manual authentication working using reproducible local writers.
Next: automatic authentication.
#Hypha new spike start (WIP): Multiwriter-2
https://ar.al/2019/02/01/hypha-spike-multiwriter-2/
In this spike I’m going to use the reproducible local writers feature I’m working on for hyperdb (https://github.com/mafintosh/hyperdb/compare/master...aral:reproducible-local-writers?expand=1) to reduce the convoluted process for authorising new nodes into the same sort of flow you would get when, for example, authorising a new iDevice.
#Hypha spike: multiwriter-1 complete.
Got hyperdb replicating between two browser nodes and the always-on-node with multiple writers (and a couple of issues). Documented current state of authorisation flow as well as next steps: to extend hyperdb so that we can pass reproducible key material for the local writer hypercores. This will allow me to reduce the authorisation flow to what you normally know when you use one device to authorise another on centralised platforms.
While adding links to Heartbeat design documents as historic reference to the latest #hypha spike post*, I ended up watching the Heartbeat initial reveal video again.
I’d highly recommend that anyone working on tools for social justice view it.
https://2017.ind.ie/heartbeat/
#a11y #accessibility #EthicalDesign
* Hypha is basically me still working on the same problem, four years later, with better tools.
Further thoughts on device authentication (and multiwriter) in #hypha. Anyone see any glaring issues with this?
https://ar.al/2019/01/22/hypha-spike-multiwriter-1/#further-thoughts-on-device-authorisation
Or please feel free to pipe up in the Datproject discussion room:
https://gitter.im/datproject/discussions?at=5c484da98318994524359c04
New #hypha spike start: Multiwriter 1
@bob @Tlacaelel Indeed. Like Freedombone ;) But even then, only because you have physical control of it. If your always-on node is to be hosted by a third party, I would limit its functionality solely to the replication of public and/or end-to-end encrypted data and without ever having the secret key. So the always-on node, in contrast to privileged servers on the Web, must be less privileged than nodes you control. At least that’s how I’m designing #Hypha.
Current state of #hypha spikes.
Cryptographically-secure passphrase → ED25519 keys → Hypercore → replicate to always-on Node via WebSocket
On always on node: join hyperswarm → replicate peer-to-peer between native clients
Also, join WebRTC swarm → replicate peer-to-peer between browser clients
All working well.
Next up: implement multiwriter via hyperdb.
Links: https://ar.al/2019/01/14/hypha-spike-dat-1/ http://localhost:1313/2019/01/20/hypha-spike-webrtc-1/
New #hypha spike (completed): WebRTC
Yay! Got the #Hypha spike replicating the hypercore over WebRTC also :) (Thanks to @joehand’s excellent example project at https://github.com/joehand/hyperdb-web-example)
Will publish the spike tomorrow :)
#Hypha DAT-1 spike complete! :success:
https://ar.al/2019/01/14/hypha-spike-dat-1/
1. Generates strong passphrase using Diceware (EFF’s word list).
2. From the passphrase, derives Ed25519 (signing) and Curve25519 (encryption) key material.
3. Uses signing keys to create an in-browser hypercore.
4. Replicates the in-browser hypercore to the unprivileged always-on node via web socket.
5. Always-on node joins hyperswarm and replicates with native client.
Replicating! :yay:
w00t! Just created my first in-browser hypercore from the diceware-generated key material.
w00T! Just created my first in-browser hypercore from the diceware-generated key material.
Next up: DAT generation :) #hypha #spikes
Text:
“Your domain name and hyphalink are two ways for other people to find your Hypha. The difference is that your hyphalink is decentralised and resilient to censorship … Your passphrase is the only thing that protects your Hypha. It is randomly chosen for you using a method called diceware that would take the most sophisticated computers today hundreds of millions of years to crack.
(Continued in image description.)
WIP #Hypha Spike start: DAT 1
Hypha Aspect Spike 1 complete: https://ar.al/2019/01/10/hypha-spike-aspect-setup-1/
We will be generating keys from a strong password + domain as salt.
Next spike: create a hyperdrive in the browser using the generated key material and replicate via WebSocket à la Jim Pick’s DAT Shopping List demo.
Hypha Aspect Spike 1 complete: https://ar.al/2019/01/10/hypha-spike-aspect-setup-1/
We will be generating keys from a strong password + domain as salt.
Next spike: create a hyperdrive in the browser using the generated key material and replicate via WebSocket ala Jim Pick’s DAT Shopping List demo.
tiflolinux.org - GNU Social is a social network, courtesy of tiflolinux.org. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All tiflolinux.org - GNU Social content and data are available under the Creative Commons Attribution 3.0 license.