SafeEditor MVP, edit your safe files directly from your browser

Apps
1

Hi everyone, I think some of you will find this useful.

SafeEditor (alpha network) is a safesite that allows you to edit your Safe APP files directly from your browser (tested in Chrome and Firefox).

1326Ă—909 155 KB

How it works

  • The editor needs to pretend it is another APP in order to access their files. Enter the information of the SAFE app you want to access. For convenience I default to SAFE Demo App, this allows you to edit any file you uploaded using the demo app, this include your safesites.
  • Press the “authorize” button.
  • Now you can create, edit, and delete your files and folders as you wish.

Limitation

What I wanted with this is to create a basic set of feature I can improve overtime. I kept the code very simple and straight-forward which allowed me to get things done quickly but comes with a few limitations.

  • Navigation is slow. Every time a change of folder is made the content is taken from the network, there’s no caching.
  • Files are not stored locally, switching to another file without saving your changes will discard them.
  • Only one file can be loaded at the time but you can load the editor in different browser to edit multiple files.
  • There’s a few graphical glitches when things overflow.

WARNING
There’s one potentially dangerous behavior you need to aware of. In order to update a file, it needs to be deleted first and then recreated. If you close your browser before the process is complete you will lose your file. Watch the little blue “busy indicator” to know when the saving process is complete.

As you will see there’s a lot of room for improvement, post features you would like to see added here, I’ll see what I can do.

That’s it, happy editing :smile:

32 Likes
2

Not tried yet, but this is excellent news, and very encouraging to see. [High five] :slight_smile:

Some of the issues you report might be eliminated with a modified approach…yes, I’m going to mention remoteStorage.js again :wink:

Firstly, RS.js gives you offlineFirst functionality out of the box, so no losing files, or edits, or having to wait for a file to upload, or worrying about your internet connectivity flicking off and on.

Next I’m wondering if users might prefer to store files they want to be editable like this on their drive, rather than in each app’s app storage. This would be their storage, still private unless they choose to store the file in a public directory, but accessible by any app.

The demo app doesn’t use the drive for storage, so it won’t overcome that problem without changing that app, but other apps designed for this kind of working could be a useful suite for doing things on a user’s drive.

For detail on how app/drive and private/public storage works, please see my post on the Dev Forum: SAFE NFS API - notes on where and how files are stored

6 Likes
3

[High five back at you] :hand_splayed:

I had in mind to use the browser’s local storage to keep all changes locally until the user is ready to submit them to Safe, this is also how Safenote works. remoteStorage is definitely worth looking into, can you access the file system with it? What’s the current state of your port?

Yes, supporting SAFE drive is part of my plan. I actually had it at first but removed it to keep things simple. About which files should a user decide to edit I’ll leave that decision to the user. I mostly thought of other dev when making this tool so they can manage the files generated by their app/safesite.

It’s also in line with the idea that users should be able to access any of the files stored into their account regardless of which app created it. This made me realize that’s it’s currently not easy to do since you need to know the authentication information of an app in order to access its files. For example I had to dig into the Safe Demo APP’s code to get them which is not ideal, it feels like a walled garden right now.

3 Likes
4

Using localstorage would work fine.

RS.js would take some housekeeping off your plate and make unsaved edits available across devices too. You’d still need to save the changes to the original file, but not have to worry about anything else to do with storing edited copies and syncing them across devices.

My update to RS.js is at POC stage - I’ve implemented almost all of what it can use, and it appears to work - very easy to take an existing RS.js app and point it at SAFEnetwork instead of an RS server. It just works! :slight_smile: The problems I’ve hit have all been to do with the apps themselves, needing to be updated to latest RS spec, or some other component being out of date, not to do with my stuff at all.

I’m waiting on a couple of CORS/CSP changes in SAFE Launcher, and one in RS.js before apps will work on a public network, but it’s easy to deal with and you could use it right now - but ask me to make sure I’ve pushed my changes if you plan to. There some docs you can look at and example apps to help you get the idea over at http://remotestorage.io

Let me know if I might be able to help, with anything, not just RS.js.

2 Likes
5

Thanks for the offer @happybeing. Looking a bit more into it and I don’t quite feel like commiting to this level of sophistication yet. The features I have in mind should be fairly straight-forward to implement for now. Syncing edited copies between device is interesting though. Maybe I could just store them in Safe in the root folder of the SafeEditor app just like I do with safenotes. That’s good food for thought, I’ll keep that in mind as I progress with this project.

2 Likes
6

SafeEditor is amazing!

Using it for the first time right now. Extremely impressive!

A small quirk I found, in case you’re interested in that sort of thing, is that when I zoom in to around 200% (I usually need to do that on my surface, as my desk keeps it far away. other users might need to as well) then the text in my file starts to disappear the more I zoom in, here’s an example:

1920Ă—1080 148 KB

But amazing work. this is super useful!!

3 Likes
7

Yeah I’m not surprised, I struggled a lot with the sizing of that box, can’t seem to make it snap correctly into its parent div. It’s on my to do list.

Thanks for the feedback, I’m glad you like the tool :slight_smile:

3 Likes
8

also another strange thing I noticed while playing with it (I know I’m missing the point, and you did this to show what can be done on SAFE, but I like to pick things apart and try to learn all I can from them. Feel free to not reply to my little things):

I can change the App name & version just fine, but as soon as I change the vendor to anything but “MaidSafe” then it won’t give SAFE_DRIVE_ACCESS and my public/ & private/ folders or any of my data won’t be available below.

Here’s an iimage of where I’m talking about. But none of this matters, I just saw it and wanted to maybe learn how that part is working under the hood:

739Ă—763 41.5 KB

9

And actually I found that I can still scroll all the way down in the visible part, so I can actually still functionally see everything, just have to scroll more.

so that means this first issue matters even less now :slight_smile:

Maybe some sort of overflow-hidden css / z-index fix. But I’m sure you would have already thought of that

10

I noticed it too. What I understand is that the SafeLauncher use a mix of the App vendor and the App id to create a unique directory structure. You can change the app name and the app version and still access the same data structure. I read somewhere they did it that way to allow an app maker to create multiple apps that uses the same data structure to share data among them.

So when you change the vendor and the id you are effectively creating a whole new data structure with nothing in it.

My experience with css is mostly made of trial and error and asking google how to do things, I’m really not an expert.

3 Likes
11

Thanks! Definitely learned something through this

1 Like
12

Amazing. Which JS library did you use to access safe?

1 Like
13

Thanks!

A custom one, it’s pretty basic and only covers a subset of the NFS API. You can check it out here if you are interested.

3 Likes
14

If this is possible how is it not a security breach on SAFE apps. I authorize SafeEditor to basically pretend it is the SAFE Demo App. What is to stop another app from doing this behind the scenes or even right in front of me? Once I authorise SafeEditor it shows up that I now have TWO! SAFE Demo Apps installed, which one is the real one?

I see a cool new app that allows me to edit my online SAFEstore online, without properly checking it out I authorise the app, it then pretends to be my SAFEstore obtaining all my store information and SAFEcoins, then it transfers all my SAFEcoins etc etc.

Please forgive my ignorance.

1 Like
15

You have to look at your launcher and not just mindlessly click APPROVE always.

This is what SAFE means, by giving control of your data back to the users, instead of large data companies

There’s responsibility with that.

16

I agree with you both. On one hand it’s important to allow other apps to access any app`s data so your data isn’t tied to a particular app but on the other hand it can also be dangerous if the user isn’t careful.

A simple solution that would go a long way to help users to be careful would be to show a special code to the user within the app that is going to authenticate and then show the same special code inside the launcher so the user knows from which app the request is coming from.

So the auth API would take an extra parameter and the launcher would show that value inside the yes/no confirm box.

17

Um, yeah, that’s not gonna work, me approving an app is not a violation of me controlling my data, it is me approving an app to give me the ability to edit while online. I approve the app that says it does one thing, then it duplicates another app and steals my data, the only way I would know the app does this is if it happened to someone else and they reported it. It even happening to someone else first is unacceptable.

“So, this new SAFE Network is out, it is awesome, i control my data, but then I downloaded a photo app so I could edit my data while online, it then stole all my data, turns out my data wasnt so safe, some safe network”

If that is the case, it is all up to me, there should be some warning saying, “if you authorise this unverified app you may lose your data”

I still dont understand how an app pretending to be another is even possible, not technically but how is this even allowed. I still dont understand how this isnt a security breach, it is possible for one app to access another apps data just because I stupidly authorised it. Doesnt make sense to me

18

I was replying to whiteout as you replied. Can you explain why this is important?

20

The idea is that you own the data. Apps are just windows to manipulate that data. If an app no longer satisfies you, you can easily switch to another app without being stuck trying to migrate your data by hand. Actually, you couldn’t even migrate it by hand if the first app doesn’t offer that feature. So in the end you don’t really own your data, the app you use does and you are stuck with it.

Take the demo app for example. You use it to create a website. But then it’s not very useful to edit the files. So you have SafeEditor that can fill that gap. At some point maybe another app will be better for uploading a website and demo app won’t be used anymore, but the data will still be the same. That’s what it means to really own your data. Apps are just workers that manipulates your data for you.

Of course that comes with security risk. The current security scheme is pretty basic and like other things feels more like a tech demo to get us starting playing with Safe. It’s gonna have to be much more flexible then that when it goes live.

Anyway, that’s how I see it.

5 Likes
21

Maybe we need to rethink the Launcher UX here, for example…

Instead of seeing the data as “belonging” to an app, which it clearly doesn’t because another app can access it with the user’s permission, perhaps “Authorisation of an app” is what is misleading here. At the moment, an app can ask for authorisation to access App or Drive:

  • App meaning, a bucket of data that is (behind the scenes) referenced using a hash based on the app’s identifying information (name and vendor I think), and
  • Drive meaning a bucket of data that any App can see providing the user “Allows” it.

What’s confusing is that any App can request and be given access to the App data created by another App - but to do so has to “pretend” to be the other App. This is very confusing in the UI, and misrepresents what is really happening.

So instead of keying the “App” data bucket using the name of the application we should see it as named bucket of data, like Drive, and which any App can explicitly request access to. This removes the need for one app to pretend to be another - it can be honest about who it is, and clear about what it is asking to access.

So instead of authorisation in Launcher saying:

Authorise Request:

AppName: SAFE Demo App
Vendor: MaidSafe
Version: 0.6.0

Permissions:
  None

             DENY  ALLOW

The app would supply a name for the each data bucket it wants to access, and this would appear under Permissions. If an app wants its own bucket, it can have it, but another app could also request access to the same bucket.

So for the SAFE Demo App it might say:

Authorise Request:

AppName: SAFE Demo App
Vendor: MaidSafe
Version: 0.6.0

Permissions:
  SAFE Demo Files

             DENY  ALLOW

Then, it would be clearer if another App seeks access to that same data, as in SafeEditor:

Authorise Request:

AppName: SafeEditor
Vendor: DavidMtl
Version: 0.1.0

Permissions:
  SAFE Demo Files

             DENY  ALLOW

I think this can be tidied up further, by hiding details that are not needed unless the user asks for them by clicking on a “more info…” link. So the authorisation message could be much simpler. For example:

SAFE Demo App ([details=more info...]
Vendor: MaidSafe
Version: 0.6.0[/details])

Wants to access: SAFE Demo Files

            ALLOW  DENY

Note: I’ve reversed position of “ALLOW” and “DENY” as I think the default should be first, reading left to right.

SAFE Demo App ([details=more info...]
Vendor: MaidSafe
Version: 0.6.0[/details])

Wants to access: SAFE Demo Files

            ALLOW  DENY
4 Likes