but if you go ahead and clone the repository, delete the
.git folder, create your own repo and set it up in the cloned folder, push it up to your new repo, then running npm i complains about building this repo
I can DM you a full stacktrace if you'd like
for example, if Bob clones that repo, he can just put ‘bob/solid-auth-client’ in the package json
I was telling you my steps for creating
my-user/my-solid-auth
still tho, you can just fork and rename the repo on github
there’s almost never a need to delete .git
and, sure, you can dm me the error
Hey there, I would like to continue working on two javascript libraries for working with acl permissions but would need some clarification of the spec:
Can multiple
Does the value of
Can multiple
acl:accessTo values be used in the same document and/or authorization? (solid/web-access-control-spec#68)Does the value of
acl:defaultchange its meaning? (solid/web-access-control-spec#63)
@Otto-AA this is the authoritative version of the W3C ACL ontology: https://www.w3.org/wiki/WebAccessControl
definitely can use multiple
acl:accessTo, it's RDF :)
@namedgraph_twitter Thanks for linking me this version. From what the wiki says it is possible to use multiple
acl:accessTo's too. Even though the solid-spec explicitly states that it differs from the wiki version, I think it is safe to go with this definition.
re authoritative version of the W3C ontology - that is not quite correct. Solid uses its own specification, the authoritative spec being https://github.com/solid/web-access-control-spec
not the wiki
it hijacks the same namespace
and adds its own semantics
I think the solid's WAC spec is very clear that this is a solid-specific version of the spec
stuff like
acl:trustedApp is not even in the ontology file
i've raised this multiple times
because it's more general than Solid
it's not a big change really, to introduce a namespace
but nobody seems to care
I suspect part of it has to do with - who has write access to those, and the general governance process, has been unclear