Could we maybe put the content of the RFC right here?

Site Feedback
1

Could we maybe put the content of the RFC right here? We do use Markdown, too after all (and makes quoting and discussing easier imho – though it does show the formatting errors :stuck_out_tongue: ):

RFC #0042: SAFE Launcher API v0.6

  • Status: proposed
  • Type: new feature, enhancement
  • Related components: safe_launcher, safe_core
  • Start Date: 01-09-2016
  • Discussion: (fill me in with link to RFC discussion - shepherd will complete this)
  • Supersedes: (fill me in with a link to RFC this supersedes - if applicable)
  • Superseded by: (fill me in with a link to RFC this is superseded by - if applicable)

Summary

Expose low level API from launcher to allow applications to allow thrid party applications
to access the building blocks of the SAFE Network.

Motivation

Exposing low level apis allow dynamic applications to be built on SAFE Network.
Using the StructuredData API third party applications can build and manage their
own data structures to fit their needs.

Detailed design

Expose low level building blocks via launcher for third party applications, which
will allow building their own data structures. Moreover, dynamic applications can be
built on using the appendable data api.

The low level apis use the FFI interface for low level API as detailed in the
safe_core low level RFC

APIs for,

are exposed from the launcher through the REST interface.

Permission

Application must request for LOW_LEVEL_API access permission to invoke the low level api to store or
read encrypted data.
Since low level apis can be used to create data in the network, it might be possible where
the data created by the apps cannot be deleted by the user again to retrieve the lost space.
Thus, it makes it important to request user for the permission to access low level apis.

Unauthorised access

Unauthorised access is granted for reading public data using low level api by default.

Handle Id

The low level apis return Handle-Id corresponding to the data type that is being worked with.
For example, the structured data will return a DataIdentifier-handle-Id using this Handle-Id,
the operations can be performed on the structured data.

It becomes the applications responsibility to drop the handle after the usage.

Limitation

Ability to work with versioned data is exposed only from low level APIs. Launcher’s
NFS API doesn’t support versioning yet.

Drawbacks

If the handle id is not cleaned up properly it can lead to memory leak. safe_core
can purge if the number of handles goes above a certain threshold.

Alternatives

Nil

Unresolved questions

Nil

1 Like
2

Rather not. If the original rfc gets updated, there are two places to keep in sync and discussions that will need to reflect stuff accordingly. would vote to quote relevant parts in the discussions but duplicating in a dev forum is prolly not adding much value. Keeping content in sync(editing original post here and updating content) will also loose relevance of original comments.

1 Like
3

Fair enough. Though I think discussion here is much nicer/better than via github (with the better quoting and referencing facilities). I pictured from the posts here that this might be an effort to move the conversation here rather than do it through github issues (which I’m definitely in favor of).

I thought that in that case, there would be new topics per status again. So you’d not update the original post but rather post a new reply when there are updates during the discussion and would have a new topic (with the old one closed) with a full new copy in it.

(That said, I have done plugins and other development in and around Discourse and I could also make a travis-script that creates/updates an RFC on every push. Not that hard really…)

2 Likes
4

That is very much the idea. as in move away from github issues and keep the discussions here. Its more about manual syncs and the value there is with an RFC sitting in github before its accepted if its replicated elsewhere. We could say get the rfc raised in the forum until its accepted and move it to github once accepted for example and keep it all here till then.

RFCs also mutate while in the same state, that was what I meant with updates more than switching discussions from proposed to active …

To prevent sync issues, yep a travis script via a merge trigger using the discourse gem to post updates via a bot id would be decent to satisfy the requirement and keep the sync issues out if needed. Anything that doesn’t involve manual keep in sync would get my vote :thumbsup:

Edit: script ofc also handling inline local resources from the rfc folder too ofc like other md files or image resources … :slight_smile:

4 Likes