Day 63/365 or day 20/28 for Singing Phoenix

What I accomplished today [120]

  • Our current development station is failing in multiple ways. So we're finalizing efforts to get the new system built and deployed
  • Planning out the final goals for TheGrid. Ambitious repivoting of Sapphire Pack that will place Standard Notes and Federalization at the forefront of privacy, longevity and maintainability in a quiet way.

Singing Phoenix

Again not today. 30 minutes of silence staring at the screen. Maybe I overextended myself? I want tomorrow to be much much better.

The Grid Day -181

The main issue with highly advanced or secured decentralized systems is that you either really need to know alot about very specific topics such as DNS, network topology etc or really really trust the people who implemented the code.

We want to move remove that forced trust because you don't understand what they're doing. Note we're not trying to make a "anyone can program" or "anyone can modify this product" since those products fall short and really you're giving them alot of jumbo building blocks.

Here is what we're going to be doing:

1) Providing peer to peer people based trust system.

2) Provide encrypted bilateral communication based off of DIME of arbitrary data

3) Provide encrypted server to server communication and automatic management of federation keys.

4) Provide a dual key encryption system.

The first 60 days will be spent learning aggressively. Everything we can, how it works, where SN thrives and where it falls short. How the extensions are built, how extensions communication, limitations of extensions. Does it do multi threading, what type of threading does it use, in the event local storage fills up how does it handle that. Can SN provide partial downloading of notes? How is the synchronization engine impacted by such a change?

Here is what I do know:

Extensions are messaged based. I've implemented an extension for SN called SNAT (it was at the time something I was extremely embarrassed about and quietly published with no one else knowing). Now looking back, I'm really proud, I managed to duplicate Tasks (an android application) UI along with implementing one of my proudest UI things which was the auto expanding and contracting sub task list. If I could find that code, I would publish it, it represented over a years work.

Extensions must explicitly ask for certain capabilities and the person must accept. At the time I build the SNAT extension, the API was async and I don't believe promise based. I ended up at the time implementing a SPIN lock, which delayed continuation of the code until data was retrieved from SN.

Finally the beauty of the extensions was that (at least mine) worked both in standard notes and in a plain webbrowser page.

Secondly, I also understand how SN's encryption works and have implemented a primitive at rest encrypted file system based on the SN's encryption scheme. Adding a N slot encrypted note wouldn't be TOO difficult.

Here's how the current encryption is used:

Your passphase -> derived password

Derived password -> password for specific note

So what we need to do is provide multiple "keyslot" that is multiple:

Derived password1 -> password for specific note
Derived password2 -> password for specific note
Derived password..-> password for specific note

Here's the beauty of this modification:
1) Current and older SN systems will still run and should completely ignore "extraneous" fields (just like CSS does)

2) We can implement filling in these extra keyslots by using some sort of key exchange protocol (which I'll riff on in an upcoming post) that won't expose the derived password (which is the weakpoint of the shared encryption).

I'm out of time for today but I'll detail more about it all in the upcoming days!

You'll only receive email when Cubes publishes a new post

More from Cubes