Day 61/365

What I accomplished today

  • Acquiring correct tools for new pivot [20]
    Since we've pivoted into a new launching that deals with programmings. It's time that we get the best cutting edge tools that we can. Wallaby.js such a tool that provides ability to do everything we need from real time testing, value exploration, back in time and story mode (reading tests and what was run like a big story).

  • Planning our new targets and milestones [100]
    Here is our new targets:
    1) Federated system with bridges.
    2) Calendar, Contacts and Shared Synchronized Notes
    3) Omega Protocol and Alpha Protocol

    We're so used to the network effect. Something that only grows in value the more that people use. What if we can do something completely differently? Something so radical, something that someone with a business degree would look at and cringe. Some would say that running a company where your product is open source is impossible but we've seen successes. Now we want to take that one step further:

    - Interoperate with closed systems.

    WHAT??? Imagine your friend uses Google Keep another friend uses Evernote and we use the super duper app. Imagine if we could all "JUST" work togeather. Wouldn't we be loosing money? No, because we'd be using a relay which requires the application. So we would be able to interoperate with any of our friends but our friends would only be able to interoperate with US. So the Google Keep couldn't work with the Evernote person. However we could work with the Google Keep and Evernote and even work with them both on a single note!

    Why is this valuable? Because we are reducing the barrier to actually switch. If you're able to continue working with your friends who use app X and you use app Y, then you would be happier and we would have gained at least one happy customer instead of zero. Migrations sound good in theory but often when the notes must interoperate with others, we need to provide a bridge. This bridge will server as a short term stopgap (hopefully) until the rest of their friends switch over to the super duper awesome app. This brings us to the next radical idea.

    - Interoperate with other instances of the awesome app. Here's the really really rough idea:
    A person doesn't have one place they only hangout, they have many. We should make the software the same. Furthermore, how we refer to such a person may change. We may refer to them as HybridLove but they might refer to them as SinkingVampire. There is no reason to force a person to have one identity online. What if we can create a single identity but they can choose which parts and how to show off to different people? Let's imagine HybridLove using servers Storm, Phoenix, Horizon as their home servers. That means that their data is synchronized to all said servers (there are multiple ways of doing this, some including some neat load software emulated load balancing from client). HybridLove loves sharing data with their best friends IconicLilly and DumbTurtle. However HybridLove chooses that they wanted to keep their Horizon home server membership a secret. That sounds completely fair, we all have places that are just our safe haven. So Hybrid love shares some content from Storm with IconicLilly and shares with both some content from Phoenix.

    Now if you've been following along and see that we want to protect HybridLove's memberships, isn't that all thrown away by synchronizing data between the different servers? Sure the servers can promise to NEVER EVER EVER share that information (pinky promise), however that doesn't help much. The best way is to make tracking whose is sharing with who anon. How can we possibly do that?

    Luckily, we found the answer at our acquaintances at Lavabit with their DIME protocol. No we won't be implementing DIME but we'll be implementing something quite similar. The idea is that the sender encrypts their message with the recipients key and home server target. This means that the sender's server only see's the destination server and not the specific user. The destination server see's which home server and whose it for but not whose it's from. The only case the home server will see whose it's for and from is if it's being sent to another person on the same home server. Our five eyes will only see that home server sent a message to another home server and nothing about the people communicating.

    This is important. Privacy is really a human right and we've got to make sure that we implement a federation protocol correctly, or it'll leak more data than we can possibly imagine in terms of meta data.

    Finally, how are we going to manage multiple identities? That's easy: we'll use a doubly indirect identity derivation. So let's say you login to one of your home servers, you share some form of a username and password. That's used to derive an identity. That identity is used to derive one or more sudo identities (these identities basically wrap a "mailbox" and provide access to notes stored under that identity). This means you're not accidentally leaking meta data to two different people that they are communicating with the same person.

Now you're probably wondering how do we synchronize calendars and contacts without doing what ProtonMail did which was require a custom client and prevent interoperability with preexisting systems?

That's some thing to discuss about tomorrow.

Singing Phoenix

Basic rhythm and tone practice.


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

More from Cubes