“Patter” is slang for tits in Danish 
7 Likes
There’s so many places I could go with this material 
4 Likes
I’m reading the above as “this is the place for posting about the experimental API” so…
Context
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.
Status
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.
Proposal
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:
~/SAFE/_webIDs/
\- me.happybeing/
\- profile/
\- card.ttl
Summary
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.
6 Likes
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
safe://me.happybeing/card#me).
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 
). Either way, I can happily give more pointers in the code, just give me a ping
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 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)
3 Likes
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.
4 Likes
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.
5 Likes
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.)
2 Likes
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.
2 Likes
For sure. I think we’re on the same page here.
Those WebID APIs were basically crafted for the specific purpose of the Patter/WebID Management examples. They were never really intended for full on consumption.
As we get deeper into actually designing API specs we can hopefully get all this straightened out a bit more with explicit APIs, as well as a deeper understanding of how any ID system (eg) might play into SAFE.
Yeh that makes sense.
We’re looking to standardise RDF in safe, with the (underway) client libs RDF APIs. Which would then be ported/available for other languages to do more specific RDF work.
Then, I think some offering of helper APIs could be made available for app integration (or not) as devs may prefer.
But aye, great to hear some thoughts / concerns thanks @bzee
2 Likes
Yeh maybe you’re right @happybeing. At the moment, with these experimental APIs it may not make sense to go down that road for the moment.
At least until we have the PNS system set up properly which should make it clearer / easier to implement these changes
(The experimental APIs are somewhat of a precursor to these, so they should/will be changing in the future to conform to the PNS we setlle upon with the RFC discussion)
3 Likes
But even if everyone isn’t able to build everything right now. This is great that folks are trying / forming opinions about these, as hopefully in the not-too-distant future, we can start building upon these learnings to get toward some stable / clear APIs that make sense for RDF and SAFE.
So thanks for digging in all so far! Keep em (and thoughts/criticism/concerns/ideas) coming!
2 Likes
Of course it is low priority, but a possible PNS rename was already discussed. Any ideas about that?
2 Likes
No real consesus was reach over in the thread, so no change as yet.
Though the RFC is still open if anyone is feeling strongly, i’d encourage them to dive in over there
2 Likes
This is very similar to my experiences with other parts of the API.
I think this is a general thing for the entire code base. Many parts are several years old and to me it seems to be implemented for a more narrow scope than necessary.
This is a natural thing to happen. You start out somewhere and then discover more.
For example, Authenticator, Public Containers, NFS, and many things related (it seeps into it all) - these things are very centric around a human user, and a specific usage pattern. But what is captured there, is a subset of the grander scheme IMO.
I have had a growing feeling, as things here and there become awkward ín various degrees when coding, that the assumptions made early on are going to be a hinder for full usage, which will lead to complicated and messy workarounds.
I think it would be beneficial to try think of a more generic layer, and then let the specific usage patterns be implemented on top of them. Not a small task for sure - there’s plenty of other (very important) things to do, and things are working as they are, so it is not something you’d just jump on. But I’m not sure the other option is such a great saving of time or effort, in the long run.
5 Likes
I’ve previously noted down some thoughts on how APIs could shape up from a WebDev perspective. But it’d be great, if from yalls hands on experience thus far (and in differing capacities), if you had any specific ideas around what kind of APIs you wish there were
Are there calls you’d love to see? Some you hate? All of this is super useful to hear
4 Likes