Today we are releasing the SAFE Markdown Editor along with a dev tutorial that shows how to build a text editor that stores its data on the SAFE Network
The SAFE Markdown Editor lets you create and edit Markdown files. The files are encrypted using a symmetric key, which means that only you can read them. Each time you save a file, a new version is stored on the SAFE Network. You can browse through previous versions of your files and compare the difference across versions. This example demonstrates the usage of versioned structured data.
We are also officially releasing SAFE API v0.6. We updated the SAFE API Docs website. It now contains documentation about the Low-Level API:
SAFE Launcher v0.10.0
This new version of SAFE Launcher is compatible with TEST 11. The previous versions of SAFE Launcher (v0.9.2 and v0.9.3) should continue to work fine, but we recommend using the new version (v0.10.0) instead.
- API version updated to 0.6
- Fixed issues #285, #289, #292, #293
- Minor nitpicks
- Tests cases expanded
SAFE Browser v0.4.2
We recommend using the latest stable version of SAFE Browser (v0.4.2) in order to use the SAFE Markdown Editor.
See this Dev Forum topic for the latest news on SAFE Browser.
SAFE Markdown Editor v0.1
You can access the SAFE Markdown Editor at safe://editor.safedev using SAFE Browser v0.4.2.
SAFE Comment Tutorial samples
We had to update the comments plugins to make them compatible with the latest versions of SAFE Browser (there were some changes to the authorization code).
- Compatibility with SAFE Browser v0.4.0-5 and above
SAFE Demo App v0.6.2
The previous version of SAFE Demo App (v0.6.1) should continue to work fine, but we recommend using the new version (v0.6.2) instead.
When uploading files using SAFE Demo App, the maximum file size is 25 MB per file.
- Fixed displaying service list if service home directory is not found
Other apps and tutorials
You can access the SAFE Signaling Demo at safe://mediawebrtc.ben using SAFE Browser v0.4.2.
To download SAFE Mail Tutorial, see this topic:
If you need help with anything related to SAFE Launcher or SAFE Demo App, please use the #support category on the forum.
If you need help with anything related to the Dev Tutorials, please use the #support category of the SAFE Dev Forum.
Where should I report issues?
If you know which component a bug is associated with, feel free to report it on GitHub in the corresponding repo.
If you’re not sure where to open an issue, you can simply create a new topic on this forum and add the #bug tag. @lightyear and I are subscribed to the #bug tag, so we will automatically receive a notification whenever someone adds the #bug tag to any topic. We’ll take care of opening an issue on GitHub if necessary.
If an issue is specifically related to the SAFE API, then it makes sense to use the SAFE Dev Forum. But for issues related to end-user applications (e.g. SAFE Launcher, SAFE Demo App, SAFE Browser, etc.), it's fine to use this forum (safenetforum.org). Most users already have an account here
As mentioned above, today we officially released SAFE API v0.6 and we updated the SAFE API Docs website.
We also released a new example app (SAFE Markdown Editor) along with a tutorial that demonstrates the usage of versioned structured data. The tutorial series now exposes a few use cases for appendable data and structured data. The existing tutorials are still going to be supported, but there will be a period of no specific activity in terms of new tutorials.
For the next few weeks, we will be focussing on getting the required changes for SAFE Authenticator in place.
Earlier today, we published an RFC related to the new authentication flow that was first explained in the topic about the future of SAFE Launcher. See this dev forum topic for more details.
New authentication flow
The current authentication and permissions handling flow relies on SAFE Launcher, a stateful intermediate between any particular app and the network. While this allows for fine-grained control over the access flow and user setup, it has the drawback of requiring the process to always run, keep a local state and proxy all network requests. This is particularly cumbersome on embedded devices and mobile, where we cannot provide this pattern reliably.
RFC 46 – New Auth Flow proposes to replace SAFE Launcher with SAFE Authenticator (a stateless alternative). The RFC outlines a new process to give applications authorised access to act on the SAFE Network with the user's credentials. In particular, it is designed for the mobile and embedded use case in mind.
Over the next few weeks, we are going to be implementing the changes necessary to support a SAFE Authenticator based paradigm. In addition to working in
safe_core, we will also be making the necessary changes in
safe_vault. That way, the Routing team can continue focussing on implementing Disjoint Groups and Node Ageing.
Earlier today, we published two RFCs related to app permissions and app management. See this dev forum topic for more details.
Granular permission control
Existing data types don't support granular access control which is required for mobile platforms where access to the network through an intermediary like SAFE Launcher is complicated: each app would have to receive full permissions to modify and fetch data on a user's behalf and private keys to sign it. This compromises security and allows malicious apps to get full access to the user's data.
To mitigate that, MutableData provides fine-grained access control and more narrow-scoped data operations. This data type is an evolved version of AppendableData. It combines StructuredData and AppendableData features and improves the network efficiency, saves bandwidth, and provides a standardised approach for apps to fetch and mutate data in the network.
RFC 47 – MutableData proposes to combine
AppendableData into a new single data type,
MutableData, similar to HashMap.
Authorize apps on behalf of the owner to mutate data
If the requests made by the permitted apps need to be charged these must all go through the Maid-Managers and they should know about the owner that an app is associated with so that they can charge the correct account.
RFC 48 – Authorise apps on behalf of the owner to mutate data details how apps route their mutation requests to Data-Managers and how revocation works.
Routing & Vault
We implemented the new way of collecting signatures for group messages, but there are still cases (messages from a group to itself, messages to clients) where some more work is needed. We are considering doing the accumulation in the group itself instead of in the first hop (a neighbouring group) to simplify the message flow.
Debugging and re-enabling the mock Crust tests is still ongoing (it’s a lot of tests!), but we’re making steady progress.