POC applications for identity management and RDF data

@joshuef Not able to use atm but just a quick note to say that I had auto - auth set when the problem started and turned it off to see if that was causing the problem.

1 Like

I think auto-auth just masks the issue (you dont see the error message).

The most annoying thing about this bug is how randomly it occurs. I’m pretty confident you’ll see it again… at some point. :frowning:

I have an inkling about what causes this though and just testing something now… fingers crossed. If i don’t see the message locally for the rest of the day, I’ll update in here.


It’s not what I thought. Back to the drawing board on this one.


I’ll try again tonight but since yesterday on multiple attempts I can’t get Peruse to pop up for reauth. I’ll create a new account and start fresh to see if I can get the logs!

I have a feeling that web-id have potential to be a real game changer, “one account to rule them all” which gives users so much potential value in effectiveness when time comes to switch from todays web to SAFE.
@joshuef @hunterlester @bochaco

Will there be an option to lock web-id so you can open many tabs, so that the web-id you choose to lock will follow to every new tab you open and stay “signed in”?
To copy/past text (mouse) and scroll zoom with (ctrl+mouse scroll), in Peruse, will that work in the future, don’t seem to work for me in the moment.


Should do. We’ll be gong through some more stabilisation milestones and adding in basic missing features in the near future.

I could certainly see this being a useful feature. Setting a ‘default’ id. Or perhaps associating an ID with a url by default…


I have the same error as @Nigel.


Yesterday all was OK. This morning, in other computer, no problems, but this night the error persist even close/reopen the browser several times.

The Log:

T 18-07-31 00:16:12.285699 [ :147] Creating unregistered client.
T 18-07-31 00:16:12.287701 [crust::main::service service.rs:556] Network name: Some(“alpha_2”)
T 18-07-31 00:16:13.290368 [crust::main::service service.rs:82] Event loop started
T 18-07-31 00:16:13.290368 [crust::main::config_refresher config_refresher.rs:44] Entered state ConfigRefresher
T 18-07-31 00:16:13.290368 [ :1395] Waiting to get connected to the Network…
T 18-07-31 00:16:14.374088 [crust::main::active_connection active_connection.rs:63] Entered state ActiveConnection: PublicId(name: 34e3eb…) -> PublicId(name: 3a602f…)
T 18-07-31 00:16:14.374088 [crust::main::active_connection active_connection.rs:110] Connection Map inserted: PublicId(name: 3a602f…) -> Some(ConnectionId { active_connection: Some(Token(24)), currently_handshaking: 0 })
D 18-07-31 00:16:14.374088 [routing::states::bootstrapping bootstrapping.rs:266] Bootstrapping(34e3eb…) Received BootstrapConnect from 3a602f…
D 18-07-31 00:16:14.374088 [routing::states::bootstrapping bootstrapping.rs:332] Bootstrapping(34e3eb…) Sending BootstrapRequest to 3a602f…
D 18-07-31 00:16:14.412113 [routing::states::client client.rs:91] Client(34e3eb…) State changed to client.
T 18-07-31 00:16:14.412113 [ :1413] Connected to the Network.
D 18-07-31 00:16:54.196445 [ :44] ERRNO: -205 IpcError(StringError(Utf8(“invalid utf-8: corrupt contents”)))

1 Like

Perhaps it could work a bit like container tabs in Firefox? With color coding etc to easily tell which is the tab is using


I try in other computer and work OK.

Strange, the main difference between both is the windows version. Windows 8.1 (error) vs Windows 10 (OK).

A small update to the browser builds (i will update the OP too):

Fixes webId urls such that safe://myid.atjosh/#me works without rewriting to an invalid safe://myid.atjosh/#/me url.

Adds a link to the authenticator to the webId dropdown/


Do we have an up to date list of profiles?

“Patter” is slang for tits in Danish :grin:


There’s so many places I could go with this material :joy:


something about decentralised ids . Maybe useful.

I’m reading the above as “this is the place for posting about the experimental API” so…


Having taken a pause with SAFE Drive etc I’m back to working on compatibility with Solid apps (SAFE Plume was almost a year ago!).

The aim is for someone who has a Solid app to be able to run it on SAFE with as little work as possible, and for anyone familiar with creating Solid apps, or who knows the web specs relating to Solid (RDF, WebID and LDP) to find it easy to migrate to or build directly on SAFE.


I’ve updated the SafenetworkJS support for LDP which was used in the Plume demo, and created a fork of solid-auth-client. Using those, and no other changes, I have one Solid app working (solid-filemanager but not yet ready for public consumption.

This demonstrates that authorisation and simple file access can work without code changes to the Solid app (though it is only the first so I’m not sure how many apps this will be true for).

Now I’m looking at how to make access to WebIDs work equally smoothly. I have the same app picking up the SAFE WebID (again without code changes to the app), but the SAFE way of tying the two together (WebID and storage) is non-standard, and would not work as is.

I have a solution in mind using my LDP emulation, so that if a Solid app tries to access storage based on the WebID (as solid-filemanager does) it can ‘just work’ without code changes, as follows:

Attempting to follow convention, solid-filemanager assumes that storage for a WebID safe://me.happybeing#me will be accessible at safe://me.happybeing (it assumes the ‘host’ will be the root of storage which is the case for a Solid POD, and I think other apps will make this assumption even though it isn’t mandatory). I can emulate that, and provide ways to determine the storage location from the WebID profile, but the SAFE API doesn’t represent this in quite the way Solid does which will be confusing and make it hard to provide a seamless way for Solid apps to access WebID profiles. This is because Solid WebIDs are typically represented as safe://me.happybeing/profile/card#me rather than safe://me.happybeing#me.


So I’d like to suggest that the SAFE WebID API (or rather the URI representation) be changed so that a SAFE WebID includes the profile as well as the ‘host’ (i.e. safe://me.happybeing/profile/card#me). This may seem clunky to those implementing the Maidsafe code, because a SAFE WebID is not a file (it’s an entry in the _publicNames container), but it is intuitive as an API and for my emulation at least it will enable greater compatibility with the Solid API. It also makes it easier to map this API in an intuitive way to other apps such as SAFE Drive.

For example, in SAFE Drive I could implement a _webIDs folder much like _webMounts, where the former would contain a directory for each WebID and the profile would be represented as a file in the directory, as if it were part of a storage container which I can create automatically. In this way, a SAFE WebID URI and profile could be accessed in exactly the same way as on a Solid pod, and as part of a file system UI. For example, a SAFE WebID of safe://me.happybeing/profile/card#me would appear in SAFE Drive as:

 \- me.happybeing/
     \- profile/
         \- card.ttl


By changing SAFE WebIDs to follow the convention for WebIDs in Solid (i.e. safe://me.happybeing/profile/card#me) they will be recognised as a WebID by anyone familiar with Solid (whereas safe://me.happybeing#me will not), and they will know how to access and modify the profile using the API (LDP) which they already know (and can emulated on SAFE). This can also be represented in a consistent way as part of a filesystem. By eliminating the ‘card’ from the URI all of that becomes harder.

And getting back to the other, more important aim, it makes it possible for more Solid apps to work on SAFE without code changes.

@joshuef @lionel.faber If there’s a better place to file issues, let me know and I’ll add this there.



Actually it is a file (in the same way as any data there may be. We can treat it as a file for this discussion).

So there’s nothing stopping anyone creating that WebID profile document file as a card ‘file’ of a website saved onto safe. That’s totally possible while keeping the same data that is the WebID accessible as XOR-URL, or wherever else you want to link it.

Looking at this in terms of proving the concept w/SOLID:

What we do now, with the web-id-manager, is that we’re just creating a domain that points to the Web Profile Document. This could be tweaked to create the card ‘file’, pointing to the same data as the PNS domain points to (so that the webId would be accessible at both: safe://me.happybeing#me AND

Doing so shouldn’t be a crazy feat (and I think might not actually cost any more PUTs that it does just now. Though im not 100% on that), which I think we’d happily accept a PR on (or you could create your own fork of it and publish that way, such is the power of RDF :smiley: ). Either way, I can happily give more pointers in the code, just give me a ping :+1:

Now, if that’s a desirable convention to have as standard is another question…

I don’t think we can answer that until we’ve had a proper look into how IDs will work on SAFE, and to what extent such compatability should be baked in.

ie: If the SAFE ID setup ends up being different, doing this SOLID setup will cost more. So should that be optional?

Or is there a way to enable that by default, while still providing whatever UX experience in the rest of SAFE, we think is best?

But aye, @happybeing, I think it’s totally possible to get this going so you can continue w/ SOLIDing things :+1: And this is definitely something worth considering as/when we get to looking at ID integration on safe and the url structs we want! (@JimCollinson FYI)


Thanks Josh, it sounds like a small tweak design wise, and would put SAFE WebID on the same footing as other SAFE services, and by using an NFS container to hold the card.ttl file would make everything compatible (ie it would be very similar to SAFE www service) both across SAFE apps and between SAFE and Solid.

I don’t know if there are reasons for SAFE ID to diverge from WebID, because they latter seems very flexible, but I don’t know much about this area.

I don’t know if it’s a good idea for me to implement changes for this. It would be easy for me to break stuff without realising - and presumably several things would need to be updated together in different areas (browser, WebID manager, possibly patter?) so not a simple fix. I think it’s better for me to focus the time I have on Solid, SAFE Drive and DWeb. By making Solid apps run on SAFE I think we get a lot of bang for our buck (apps to use, exposure, plus getting like minded folk from the Solid community interested in what SAFE can add to Solid). I still have work to do with LDP so I’ll continue there for the time being.

LOVE IT. Lets do it PLEASE

1 Like

SAFE should also ensure that SAFE WebIDs are compatible with open standards for DIDs and W3C initiatives. We need it for SAFE to be successful without compromising the mission of the SAFE Network.

I’ve had some remarks in the past about modularity of the API. Thought this might be a good example.

You might opt to make it so the developer can pass some parameters to influence this. Exactly because there is no fully adopted standard or convention these should be left open for the developer to decide. With writing some Solid/SAFE code I ended up wanting to re-implement a few things because the current APIs are not very modular. It’s all made with a specific purpose and a single deviation means the API is not suited.

The fact the Node.js API bakes in a lot of decisions is also a good thing because it forces all SAFE developers to do much of the things the same way. But ultimately I think everything should be made more explicit; whether through documentation or (preferably) through API design.