Here are some of the main things to highlight this week:
This week, we're giving a big shout out to @ oetyng who has set up not one, not two, but three new Meetups in Sweden! Stockholm, Gothenburg and Malmo now have their own SAFE Network groups. As ever, if you've got a meetup account, please do join each of the groups and help @ oetyng to get the groups off to a flying start!
@ dugcampbell was down at the CogX Web3 Conference in a very wet London at the start of the week (great to meet @ Bridge and @ Kafkalee in person!) and also on BBC Radio Scotland this morning opining on the new Coinbase Card. And we also sent out a new Newsletter to subscribers today - another wee content experiment, give us a shout if you liked or hated it in your inbox. Check out our latest tweetstorm and, in the coming week, if you're out and about in Edinburgh on Wednesday, we'd urge you to head along to the Scottish Blockchain Meetup where we're sponsoring Andreas M Antonopoulos' talk. We'll likely have quite a few of the team in attendance so give us a shout if you're heading along and we'll make sure we take enough swag along...
We are delighted to announce our latest project deliverable on our way to Fleming: the safecoin wallet command-line interface (CLI) - see the SAFE CLI section below for more details. It shows the basics, including (test) Safecoin and starts us on the path for full integration of this into SAFE Client Libs (coming soon!).
These deliverables will allow developers and interested parties to see the interface that will run in the Fleming release. As stated we are looking at Fleming to really bring something special (no promises, but let's whisper it since we're amongst friends... how does full vaults from home sound to you all....? ;-) ).
To accompany the GitHub boards, we're also providing you with a high-level overview of the project Gantt chart (check out the Forum):
It shows the large chunks of work that are currently in flight, each with their dependencies and sub-projects. From this, you'll see the path to Fleming involves the release of:
Then folks, we are in Fleming release territory...
We plan to share some more deliverables along the way, each setting out the functionality that the released network will use.
So how come we're doing this now? Well, it's all down to the project plan bedding in and (more importantly) a well-motivated and focused team (some too focused and working all nighters, we're looking at you @ nbaksalyar). Yup, that's right. There's a definite air of confidence brewing and we will continue to build on that as we execute the remaining deliverables.
We're happy to be able to give something that hopefully lets folks start to get their hands dirty with the SAFE CLI.
We have some initial POC work against a mocked vault (integration with the actual safe_client_lib API and mock vault will be following promptly). What does this mean? Well, it means you can dig into the SAFE CLI and start playing around with Key's, keypair's and Wallet's commands. More detail on all that can be found in the CLI User Guide, which takes the user through all the necessary steps to authorise the CLI application using the safe_auth CLI, as well as explaining what these new concepts are, and how to interact with the SAFE Network using the already available CLI commands. We highly recommend thoroughly reading the CLI User Guide before trying to run any CLI command.
Thus, as mentioned above, the CLI now creates a local file named mock_data.txt, but hopefully this lets folks see how things are shaping up and can help us get useful feedback on usability/naming, etc. Some parts where feedback and opinion would be greatly appreciated are around usage flow, argument order and naming.
It's worth noting some of the current limitations in this POC version. There's no default Wallet for an account for example, which means the payment source always needs to be specified as part of the commands. This should hopefully get smoothed out later with source becoming truly optional as it should be.
Here are some samples of what's possible right now. The following will create a Key on the Network, and preload it with test safecoins, as well as provide a nice human readable output:
$ safe_cli keys create --test-coins --preload 15.342 --pretty
New Key created at: "safe://bbkulcbnrmdzhdkrfb6zbbf7fisbdn7ggztdvgcxueyq2iys272koaplks"
Key pair generated:
pk="b62c1e4e3544a1f64212fca89046df98d998ea615e84c4348c4b5fd29c07ad52a970539df819e31990c1edf09b882e61"
sk="c4cc596d7321a3054d397beff82fe64f49c3896a07a349d31f29574ac9f56965"
Once we have a Key with some test coins, it's possible to check its balance:
$ safe_cli keys balance safe://bbkulcbnrmdzhdkrfb6zbbf7fisbdn7ggztdvgcxueyq2iys272koaplks --pretty
Key's current balance: 15.342
Many more examples are explained in the CLI User Guide.
Please share any issues or questions in the CLI thread where we can all help each other, and/or report any bugs you encounter directly in our CLI GitHub repository.
As a result of a joint effort from @ fraser, @ jean, @ lionel.faber, @ marcin, @ nbaksalyar, @ ustulation, and @ Yogeshwar, we made significant progress with the test Safecoin and the new data types implementation in SAFE Client Libs. We implemented the basic functions defined in the Safecoin RFC: creating new balances, coin transfers, and transaction detail requests. There were some other internal changes in SAFE Client Libs which should eventually help us to support multiple ownership for data and wallets through the BLS encryption.
Over the next week or so, we will be rolling out the FFI APIs which would allow app developers to use all new features. We are also planning for new refactoring and simplification work: Clients will be decoupled from Routing, connecting to Vaults directly through quic-p2p instead. This will allow us to prototype Vaults more quickly and move forward with important tasks without being blocked by Routing. Eventually, all pieces should fall into one place and Vaults will be the main (and only) consumer of Routing.
Progress on Vaults has continued this week: we are creating a version of Vaults that doesn't rely on the Routing crate. It communicates directly with clients over quic-p2p. Without Routing, it doesn't allow the creation of a decentralized network, but it can be used to model a network with a single Vault; or eventually a fixed number of Vaults. This will help us make sure we can establish the vault/clients API and allow the frontend to continue progressing at a fast pace while progress on Routing continues in parallel. This removes a long-standing bottleneck on Routing for experimenting with new data types, Safecoin and such features.
This week we've implemented some improvements regarding auto-updates, and the notification flow surrounding that. We've also been looking at how we're publishing both prod and dev versions of the browser, which has added some complexity to the auto-update feature (as this isn't supported via GitHub), so we're looking into what other providers might be best for this setup.
We are continuing work on the Reliable Message Delivery aspect of Routing. This follows the Reliable Message Delivery RFC that was recently published. The outcome of this work will be a routing network where messages virtually always make it to their destination; although the authenticity of the messages won't be verified and the system won't be resilient to spam in the first place. The first of these limitations will be addressed soon after when we implement the Secure Message Delivery RFC.
What we gain from this work is a significant simplification of the Routing code base, which will help progress other aspects of the upcoming work in the Routing crate and a sound foundation for Secure Message Delivery.
More simplifications to the Routing crate are coming by taking advantage of the new API for our network layer: quic-p2p. We can now "fire and forget": send a message and expect that it will be delivered or, in case of failure, come back to us so we can resend it. This removes a layer of complexity from Routing where we had to keep track of who was online at any given time. We can now be more loose with this requirement and simply accept a peer as responsive if the message we send them doesn't bounce back to us. The work on that track has made good progress this week and a PR should be raised soon with the bulk of the initial changes.
We took a few early steps towards enabling BLS keys in Routing by merging a pull request that adds Distributed Key Generation to Parsec. Most of this code comes from our earlier effort towards implementing a common coin, but we are cherry picking a subset of this work that will be relevant to Routing in the short term.
We will want to switch to BLS in Routing as it will allow a much more efficient way of verifying messages through Secure Message Delivery. Depending on the rate of progress of different tracks, and on whether it would ease development, we may integrate BLS in Routing before or after implementing Secure Message Delivery.
We would like to thank @ d1vyank on GitHub who has actively participated in the development of the Routing crate this week. They identified multiple opportunities for refactoring in Routing, based on FIXME and TODO comments, and raised as many pull requests to address the issues. This was really useful and we were happy to merge four of their PRs in the last few weeks, including two this week.
We would also like to shout out to @ oetyng for some more contributions on our BLS RFC thread this week, and for every other forum member who's been involved in the various RFC discussions in the last few weeks. :bow: