POC applications for identity management and RDF data

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.


This thing from Binance:


Whenever I receive communication from Binance, I have my secret word in the message.

Could we have something similar? As a convention, apps and sites would show us our secret word, stored in the account somewhere, and it would assure us that we’re logged into the right account. I’m not sure it’s absolutely necessary (it may in fact be fully redundant) but it seems like another layer against fraudulent apps.

I’m not sure it’s necessarily that complicated. It should be another entry to the filesmap RDF entry of the domain to create a ‘card’ file. As it’s an addition it shouldn’t break anything with existing apps etc. They would just ignore it.

Then you could have your SOLID WebID Manager, where users can know they’re getting this extra data created. And it is optional. Also avoids any confusion about webIDs previously created through the current webId manager not being compatible. Seems kind of ideal for the scope of RDF/SOLID etc.

I think that’s part of what I’m saying. I don’t either. But maybe there are reasons. Maybe there are various options about what could be offered to the user, as per @bzee’s suggested re: API flags to enable such things optionally. Or maybe developers will want to add this/other functionality on top?

  • Compatible how? Able to be converted to one another? Or able to be used directly?
  • Would you consider DID and WebIDs compatible? (and if not what criteria would you use to decide which gets priority?)

I’m not sure we have to make out and out compatibility a goal. It may well be desirable. It may come with too much clearnet/blockchain baggage. But we should certainly look at it and see what makes sense, that much is for sure.

Indeed. Or a standard may be converged upon. I totally agree though, whatever ‘ID’ system ends up being used in maidsafe systems, doesn’t have to be the ID system for the safenetwork.


I’d love it if you can elaborate a bit on this. Would be interesting to hear what problems you’re hitting and what solutions you’ve come up with.


From the top of my head:

First, creating a WebID with the API also implicitly added it to the public container. I remember looking at the source code for the WebID emulation and seeing the ‘side-effects’ of creating the WebID. To me, there were/are a lot of assumptions to how the WebID is supposed to be used, while as a purist I’d like to get things trimmed down at first and then possibly extend them.
Also, with the XOR URL I felt like the public name wasn’t really necessary (at least for testing purposes and proof-of-concept stuff), but the API assumes a SAFE DNS name. (Though I can’t really tell what the practical value is of not using a public name.)

Second, as a purist I looked at the WebID spec and noticed a nickname is optional (MAY). The API has the nickname as a required parameter basically. Now this sounds like a small thing, but I always view the standards as important, especially for API design.

The first point strengthens my opinion that there could be a more clear separation of concerns. Like is touched on above, what is the difference between SAFE and Solid; what do these differences mean for the APIs? Can we make apps that are ‘compatible’ with both these platforms? With the current API I have no clear sense of what is happening behind the scenes and how that relates to Solid/RDF. Or at least how to influence the behaviour that is apparently deemed as a ‘sensible default’ by the API designers.

This then further instigates my concern that the Node.js API might become too bloated and how that functionality will be implemented in other APIs. (This is something that’s more of a forecast instead of an observation.)


Same here, so @joshuef while it seems straightforward to you, to dive in and make these changes, you already know what you are talking about. I think you are suggesting I create a new option, rather than modify the existing scheme (where I was concerned about compatibility). That seems simpler, but also raises new questions - how to select the option, how that affects the browser UI etc.

From here I can see there’s learning I’d need to do and I can’t tell how much time that will take - but my experience is that it is usually quite a lot before I’ll really get to grips with things in the way you can see them.

I’m more confused now tbh.