Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 01 08:14

    csarven on 2022-11-30

    Apply suggestions from code rev… (compare)

  • Dec 01 08:14
    csarven synchronize #486
  • Dec 01 00:13
    coolharsh55 opened #487
  • Nov 30 21:34
    csarven synchronize #486
  • Nov 30 21:34

    csarven on 2022-11-30

    Apply suggestions from code rev… (compare)

  • Nov 30 16:24
    csarven synchronize #486
  • Nov 30 16:24

    csarven on 2022-11-30

    Add link to notifications-panel… (compare)

  • Nov 30 16:16
    csarven synchronize #486
  • Nov 30 16:16

    csarven on 2022-11-30

    Apply suggestions from code rev… (compare)

  • Nov 30 14:57
    csarven synchronize #486
  • Nov 30 14:57

    csarven on 2022-11-30

    Update 2022-11-30 minutes (compare)

  • Nov 30 13:59
    csarven assigned #410
  • Nov 30 13:47
    csarven assigned #486
  • Nov 30 13:47
    csarven labeled #486
  • Nov 30 13:47
    csarven opened #486
  • Nov 30 13:47

    csarven on 2022-11-30

    Add 2022-11-30 agenda and minut… (compare)

  • Nov 30 13:01
    csarven opened #485
  • Nov 30 13:01
    csarven milestoned #485
  • Nov 30 13:01
    csarven labeled #485
  • Nov 30 13:01
    csarven milestoned #485
Sarven Capadisli
@csarven
https://csarven.ca/linked-research-decentralised-web#design-decision mentions "third-party inbox-as-a-service" as a way to meet some use cases.
Fred Gibson
@gibsonf1
@csarven Thanks!
Sarven Capadisli
@csarven

@edwardsph https://github.com/solid/specification/issues/158#issuecomment-606503695 , in particular:

When I suggested this I was thinking of two areas of use: http 301/302s to https or location of (an inbox) container changing.. and if the original request is a POST, I'd still like it to go through (I think).

So I think we can do "301 or 308". I do remember related discussions where we don't double down on specific status codes when redirecting is needed.

I actually had this issue in my own publishing + application e.g., I used to use http://csarven.ca/inbox/ (also one of the examples in the LDN spec) but then later switched to https. So, POST to http and server responding with 301 didn't work out. 308 would be great.
Sarven Capadisli
@csarven
I think it makes sense to not use 302/307 for http->https because of the requirement to persist the redirect (301/308). I can't think of a good reason why a server may want to turn off the redirect if they still want to support http and https. That'll expose two different URIs which is undesirable/not good practice. If a server doesn't want to support http or https at the same time, that'd a different case.
Aaron Coburn
@acoburn
Noting that a server may implement support for Strict-Transport-Security headers, which is considered best practice and more secure than merely relying on 3xx redirects https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security (HSTS is orthogonal to the Solid protocol specification, but the Solid protocol specification should not make HSTS difficult to implement)
Sarven Capadisli
@csarven
True that. The current language didn't intend to ignore / overstep server's HSTS support. We should encourage HSTS.
Sarven Capadisli
@csarven

We are asked to renew or remove our expression of interest for the W3C RDF Dataset Canonicalization and Hash Working Group Charter (formerly Linked Data Signatures): https://github.com/w3c/rch-wg-charter/issues/49#issuecomment-1027048465

Has there been any changes in our interest? As with our original support, this is an important undertaking for all communities that works directly/indirectly with RDF and I suggest that the W3C Solid Community Group should +1.

3 replies
Kjetil Kjernsmo
@kjetilk
:+1:
Sarven Capadisli
@csarven
Should the Solid Protocol limit the JSON-LD requirement to one of the Forms as opposed to all (current)?
1 reply
Justin Bingham
@justinwb
This message was deleted

Has there been any changes in our interest? As with our original support, this is an important undertaking for all communities that works directly/indirectly with RDF and I suggest that the W3C Solid Community Group should +1.

+1

Should the Solid Protocol limit the JSON-LD requirement to one of the Forms as opposed to all (current)?

i don’t think we should limit anything at this time - maybe never. i like @acoburn’s suggestions about establishing best practices and documenting patterns over restriction

దామోదర
@damooo
Hello all, Can there be auxiliary resources for some auxiliary resource in general? There seems discussion on acls for some kinds of auxiliary resources. If so, is there any limit to chain?
Sarven Capadisli
@csarven
No particular limit mentioned in the spec but no particular behaviour defined either. Subject resources (the ones that have auxiliary resources) are typically - only typically - contained resources. At the moment, auxiliary resources are not contained resources. So, ACL resources could have ACL resources... or ACLs could have Description Resources.... and yes, re discussions/considerations on some auxiliary resources - only description resources as far as I know to date - could have their own ACLs. The Protocol is currently not preventing different ways this could all happen. We need rough consensus and running code to hash these out.
దామోదర
@damooo

Thanks @csarven ,
I saw some discussions about access-log aux resources, which may have their own acls, etc. For now, i take it to be any long chain in general case.

Also is there any absolute-term for those subject resources, that which is not in relation with aux resources? like some "primary resources", etc?

1 reply
or "principle resources"?
Sarven Capadisli
@csarven
Just resource. Contained resource.
Martynas Jusevicius
@namedgraph_twitter
Is Solid still compatible with Linked Data Platform?
Sarven Capadisli
@csarven
Some compatibility and nothing overly conflicting. Possible to take an LDP server and have it conform to Solid Protocol. There may be a section in an upcoming version explaining the relationship/divergence further. Solid borrows LDP's concept of basic container and resource containment. Besides using POST to create a container where the server assigns the name, there is not much particularly required from clients to know about LDP. There is a bit more detail on Solid/LDP server/client compatibility here: https://github.com/solid/specification/issues/194#issuecomment-694828342
sjoertrix
@sjoertrix:utwente.io
[m]
We think a lot of people like Solid, nobody wants to run their own server, but people do want to use their own domain. Use the domain for ID and use the domain for storagepods.
As I am sure we are not the first, could somebody point me to some sources where some of the ideas/options have been discussed already?
sjoertrix
@sjoertrix:utwente.io
[m]
Being able to serve a domain could be a step toward people running their website from their Storage pod.
This is a URL/application which shows a website: https://yvo.muze.nl/simply-edit/examples/solid-storage/
The site data is stored on solid-nextcloud.muze.nl
And it can be edited with a webid from solidorg.net (we can add other users in the ACL, let me know if you would like to test)
The CMS used is SimplyEdit, frontend CMS. With these building blocks, what would be needed is a server listening to domains and serves a html file from a certain storage location.
Sarven Capadisli
@csarven
Do any servers return 403 on OPTIONS?
1 reply
Fred Gibson
@gibsonf1
@sjoertrix:utwente.io supporting custom domains would be an implementation decision, and trinpod.us and trinpod.eu will let you use your own domain with commercial launch coming in a few weeks
2 replies
Fred Gibson
@gibsonf1
@csarven I'm looking at the activitystreams ontology, and this seems confusing:
as:actor a owl:ObjectProperty ;
  rdfs:label "actor"@en ;
  rdfs:domain as:Activity ;
  rdfs:comment "Subproperty of as:attributedTo that identifies the primary actor"@en ;
  rdfs:subPropertyOf as:attributedTo ;
  rdfs:range [
    a owl:Class ;
    owl:unionOf (as:Object as:Link)
  ] .
for range, shouldn't it just be as:Object ?
Oh, as:Link is not a subclass of Object, hmmm

I'm not sure how a Link woudn't be a subclass of Object? An easier to use hierarchy could be: Link subclassOf Object . Entity subclassOf Object . Activity subclassOf Object . Condition subclassOf Object.

Then
Collection subclassOf Condition . OrderedCollection subclassOf Collection.

Fred Gibson
@gibsonf1
Actually, you could argue that the Link too is conditional, so Link subclassOf Condition
I'm definitely of the firm opinion that a good ontology has only one class as range and domain, and if that isn't possible with a given ontology, then the ontology has issues that need resolving
Fred Gibson
@gibsonf1
But that said, this spec is fantastic https://www.w3.org/TR/activitystreams-core/
Fred Gibson
@gibsonf1
Actually, I've solved the hierarchy issue in our ontology by defining all as:Object, as:Activity and as:Link as conditions, so they don't interfere with our core ontology. That is, these types are conditional based on, for example, use of them with as predicates etc and thus don't interfere with the core definitions for an Object and Event, etc
Fred Gibson
@gibsonf1
and then added a class to which both as:Object and as:Link are subclasses to avoid the complex range definition: : as:Object rdfs:subClassOf neo:s_activitystream-class. as:Link rdfs:subClassOf neo:s_activitystream-class .
so then it would be just rdfs:range neo:s_activitystream-class
Would be great if the ontology could be updated to do something similar and treating these items as conditions
Fred Gibson
@gibsonf1
This also allows integration of as:Activity as both a subClassOf event:Event and s_activitystream-class, so the Activity can be inferred as an event (where event:Event is the neo core definition for an actual event in the world)
Fred Gibson
@gibsonf1
Also just noticed: IntransitiveActivity Inherits all properties from Activity except object. Which actually means that Activity should be a subclass of IntransitiveActivity
Fred Gibson
@gibsonf1
Actually I'm strugging to understand or find an example of an IntransitiveActivity, that is an activity for which there is no object. Does anyone have ideas?
For example, this is the example used:
{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Travel",
  "summary": "Sally went to work",
  "actor": {
    "type": "Person",
    "name": "Sally"
  },
  "target": {
    "type": "Place",
    "name": "Work"
  }
}
However, Sally is the object of this activity, there is nothing intransitive about it
So maybe the idea here is to leave the object off if the actor and object are the same?
Fred Gibson
@gibsonf1
That is, the event in which Sally performed a move of herself "went" changed her input state "location:somewhere not at work" to her output state "location:work"
Aaron Coburn
@acoburn
Sally is the subject. Grammatically, there is no direct object. I would reccomend looking up "transitive verbs" for more examples
*intransitive verbs, that is
Sarven Capadisli
@csarven
@gibsonf1 AS ontology - I assume you're looking at the Turtle - may not be accurate. It was not finalised.
Jeff Zucker
@jeff-zucker
interop folks - how is the exclusivity of an AuthorizationAgent enforced? If I have an old-style app with write perms on the whole pod, what is to prevent me from writing stuff only the AuthAgent should write to? Does the AuthAgent, the first time it is invoked go through and create .acls for itself?
What's then to prevent an app with Control from re-writing those?
elf Pavlik
@elf-pavlik

We are still polishing details. I see it in the following way:

  1. Authorization Agent creates Access Consents and based on them generates Access Grants
  2. Authorization Server (associated with given Resource Server) can access Data Grants applicable to given RS and based on them sets ACRs/ACPs/YouNameIt-s

In that case Authorization Server associated with Resource Server (RS would advertise it via as_uri in WWW-Authenticate would be the exclusive party to create ACRs/ACLs/...

This doesn't require anything like acl:Control access mode at all, the association between AS and RS is pre-established.

With this approach, Access Consents would be the single source of truth, Access Grants are derived from those by AA, and ACRs/ACLs/... are derived from Data Grants by corresponding Authorization Servers.

Introducing another source of truth can lead to various issues, policies set directly in ACRs/ACLs could be easily overwritten.

I think we could have different approaches coexisting but preferably in different storages, solid/specification#377 could possibly address it as well, where one storage type would be AS managed and another could allow raw ACP/WAC/YouNameIt policies.
We have been diving into that during Wednesday AuthZ calls and I expect we will continue working things out during next weeks.

The approach discussed above has the advantage of only AS and RS needing to agree on ACP/WAC/YouNameIT, clients (apps) only need to understand Data Grants (read-only), and Access Needs. Authorization Agent stays responsible for dealing with most interop nuances and it would rely on AS to set policies on RS based on Data Grants (also read-only for AS)
Jeff Zucker
@jeff-zucker
So basically there would be old-style storages and new-style storages and never the twain shall meet ? Only old-style apps can access the former and only new-style can access the latter? That does not seem workable to me.