It’s been an encouraging week in our investigations into private, unlinkable transactions, with @danda hitting on a way to introduce blind signatures for DBCs which should make transactions totally unlinkable as well as super-fast and efficient for the mints. He is currently working on a simple, developer-friendly API for blind signatures which will allow BLS signature aggregation. We’ll be kicking off our overview of the Safe Network economy ‘soon’ with a deep dive look at the tech behind DBCs, but this week’s main focus is on the user experience progress.
@oetyng has been chiselling away at the self-encryption library. As well as the massive speed improvements mentioned over the last couple of weeks, the API is now simpler and more flexible, where the need for passed-in storage has been eliminated. All of this, and dispensing with more than 3,600 lines of code in the process! This is now being PR:ed into main.
@bochaco and @qi-ma have tracked down a CPU-bashing bug that occurs when a section is formed. It seems that the elders are generating keys - i.e. reporting elder churn events - when they don’t need to, resulting in a flood of messages between nodes.
Relaying of client messages from one section to other sections - for example when a client requests to PUT chunks to multiple sections - has now been deprecated in favour of clients speaking directly with the appropriate sections, as mediated by Anti-Entropy. @yogesh has got the initial implementation passing CI tests now.
There’s been a bit of a rush of new tech incoming to the Safe Network, rapid changes under the hood—and of course the predictable flood of new acronyms that entails : CRDT, DBCs, BLS, etc.…
It can be quite a task keeping up with it all and trying to pick through what exactly it all means (if it makes you feel any better, I struggle with that too ). It might even leave you with the nagging question “is this all necessary? Can’t we just keep it simple?”.
Well, all this tech is being deployed in order meet the Network Fundamentals. Our aim, as always, is to uphold these fundamentals, and get the Network launched as quickly, and via the most efficient route.
While on the face of it this may all seem like only the inner workings of the Network, they of course go hand-in-glove with the upper layers, what you and I and everyone will experience when we use this Network. And that’s where—if you’ll allow me—I get to be a little excited about what these changes mean for the UX, and how the Network will function for people. In fact this allows for a simpler solution both conceptually, and practical use-cases too.
For instance, things like CRDT (Conflict Free Replicated Data), DBCs (Digital Bearer Certificates) and pre-upload Self Encryption, allow the Network to function as we require it to, and for the nodes to do there thang efficiently and securely… but they also allow the user to work with the Network across multiple devices, with varying states of connectivity—online, offline, and the flaky bits in between—sympathetic to the reality of modern digital life.
Making complex things simple to understand and easy to use is, well, hard and complex. But this is again where we reap the benefits of all the developer effort and brain-ache: We’re able to enrich the metaphor of a user’s Safe, and make it even more elegant.
A ‘Safe’ is the the conceptual structure I create to contain and manage my data, keys, money, identities, preferences etc. and it can now be created, and start offline, then be added to the Network (drip-fed even) allowing it to be accessed from anywhere. It allows for periods of offline work, syncing online later even across multiple devices, but still maintaining the same single conceptual space for my data. Beautiful!
And what’s more, accessing and handling the funds, the tokens, to make this all happen (if indeed I need any funds at all ), becomes an easier prospect thanks to the nature of DBCs. Passing them offline, in person, or via the clearnet, or direct across the Safe Network; all these avenues are open now. I just deposit them in my Safe and I’m up and rolling!
But with all these new possibilities allowing for the enhancement of the UX, and a reassessment and reassembly, of the building-blocks so far, how do we make sure we are designing the right thing fore the right people?
The tech is evolving, as are the external factors such as the market we’ll be launching into as well. So we pave the way with user research of course! trumpet sounds
It’s been quite a turbulent time for the world, for technology, and in particular the crypto commercial and regulatory space. So it’s wise for us to seek out the path of least resistance to getting the Network on its legs, and thriving.
We’ve been working with an organisation called Critical Future in order to aid our market research, as a jumping off point for deeper user research. Some key takeaways so far, when it comes to what is valuable to end users:
- Clear and understandable pricing
- Transparent T&Cs (or indeed perhaps the lack of a need for them) that I can trust (or don’t need to trust)
- Ease of use
- Multi device usage and synchronisation
- Mobile access
- Privacy and data security
- Increasing the utility of crypto
- Strength of token value
Teasing out the details of their work, we find they’ve identified three significant sub categories of end users that will likely drive the adoption of the Network in the beginning: Data Horders, Privacy Devotees, Crypto Pioneers. We’re just talking about end consumers here by the way, this isn’t including any additional provision that we’ll need to consider for institutions, enterprise, or 3rd party developers.
So we are deep into a period of ongoing research in the needs of these early adopters, so consider this just a sneaky peek at what we are working on. A tantalising name-drop if you like!
So in cometh the enhanced, more flexible, and salivation worthy tech; a clarifying review of the users we are building for; and on top of that we can layer a set of criteria, or constraints if you will, to focus this design work on a launch ready, robust product:
- We should accommodate a healthy app ecosystem, but must not rely on it. We need to offer immediate value to users, while allowing the the 3rd party developer community time to mature, should it need it.
- We should and can be hopeful of snappy performance, but we should design for usability with slower than typical clearnet speeds in mind.
- We may not have all the bells and whistles at launch (for example RDF, or network wide search) but we can still make a game changing product that can make a big difference and then expand it from there.
- Building flexibly for economic on-ramps and off-ramps. We need to make Safe Network Tokens as broadly accessible as possible.
- We should be most concerned with the supply of data to the Network. The security, economy, marketing… it all hinges on solving this, the data supply question: how do we make the Network a really useful place for people to store their data?
So yes yes, I know you’ll want to see real moving pixels on all this, and an app in your hand that just does that thing… and that is on the way, I promise! But design work, and the UX design of a replacement for the web in particular, requires a lot of thinking, testing, observing and talking. So hopefully this gives you a glimpse of all the work that is currently ongoing in that regard, and how the highly clever network code comes together in a way that will be the game-changer we all know it can be.
Feel free to reply below with links to translations of this dev update and moderators will add them here:
As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!