Thoughts on Safe Development
After investing a non-trivial effort in developing an app for the SafeNET (check us out on github at: GitHub - Frames-Proj/frames). I have a few thoughts on the Safe dev process.
Protocol Oriented Development
The lack of ability to write any sort of centralized logic might seem intimidating when you first start trying to think about how to design an app for the SafeNET, but once you realize that your job as a developer is to design a protocol rather than write a server, things become easier.
There are some things we are used to on the clearnet that become difficult in protocol-oriented development (such as the ability to have very fined grained control over what your users can and can’t do). Some things seem to be impossible (such as maintaining an efficient search index). As a protocol designer you have to think about attack scenarios first and foremost, taking into consideration the inevitable shenanigans of malicious users.
One attack scenario we thought a lot about while developing Frames was the possibility that a user would decide to unpublish his or her data. I think any app that goes live on the SafeNET should publish its protocol spec before going through a beta period on a testnet of some sort where the developers ask the community to break the protocol. Even better would be to publish a library that already knows how to talk the protocol.
Tooling
App devs could definitely use more and better tools. This is to be expected for a project still in its childhood like the SafeNET. The mock_routing crate is great for developing against a consistent interface, but it does have a few drawbacks. The most obvious is that you are not working with a real network. To solve this some sort of safe-in-a-box style solution would be good to have. Another issue with mock_routing is that as far as I know it only supports a single user. Testing the interaction between multiple users is vital for protocol development, so this feature should definitely be added at some point.
The concept of the safe_launcher, to provide a central gateway for access control on the safe_net, is good, but I’m glad that the community decided to switch to the authenticator. The first issue was performance. Frames makes dozens of requests a second when it is fetching a screen full of un-cached videos for the Discover or Me page. The launcher is slow at the best of times but when I opened the log tab to watch the requests stream by I was only seeing about one request per second go through. The second issue is the lack of a headless alternative. Frames only builds the code during continuous integration (automatic testing run on every PR) even though we have lots of tests that we would love to be running. In order to do this we would have needed a version of the safe_launcher that did not have a GUI and automatically authenticated.
I talk about the launcher in part to try to make sure people understand what the pain points are for developing real apps. The authenticator cuts out a whole layer of unneeded REST calls, and gets my access to the network a comfortable distance away from a UI thread, so it looks like performance is moving in the right direction. I’m a bit more worried about the lack of a headless alternative for developing against mock (or safe-in-a-box). I could obviously fork off (and that is what I will eventually have to do if this does not get any traction), but I would rather that a headless authenticator/mock network is maintained by the core team.
It has been pointed out to me that it is possible to just generate an auth token in the GUI and store it in a config file, but I don’t want to do that for a couple of reasons.
The most important reason is that I don’t want to store access tokens in the clear. The authenticator acts as an awesome password manager, and I don’t want users to have to worry about their tokens getting stolen. The more we can reduce the attack surface of user’s interactions with the network, the better. I know that there are good arguments for storing tokens for IoT applications, but there is a security trade off that I don’t think is worth while for apps.
The second reason is continuous integration. I’m not sure how pregenerating an auth token will allow me to run travis tests because each test will stand up a new mock (or safe-in-a-box) environment. The least important reason is just a personal preference for command line applications.
This week in Frames
I promised I would include updates on what I’ve been doing on Frames during the week whenever I made these posts. I noticed that GitHub - Frames-Proj/mock-safe-launcher: A pinned version of the Safe Launcher for use testing Frames had suffered a little bitrot, so I fixed that. If any of you were having trouble getting it to work, you should have better luck now.
I’ve been working to get a mock-authenticator built, but am blocked on a build bug from upstream. I have been working on Frames mostly on the train when I don’t have access to the Internet, which is fine for app dev, but tougher for debugging build bugs, so my forward momentum has slowed a bit. I’m going to try to get some sort of mock-routing solution up and running so I can dive into API migration, but it may take a few weeks. One possibility I want to look into is to fork safe_client_libs and alter it to auto-authenticate when built against mock (or more likely add a new feature flag).
