Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 03 16:06

    csarven on main

    Update work-item-technical-repo… (compare)

  • Feb 03 15:21

    csarven on main

    Add view potentialAction for un… (compare)

  • Feb 03 13:35

    csarven on main

    Add Solid QA work item (compare)

  • Feb 03 11:48
    csarven commented #495
  • Feb 03 11:18

    csarven on main

    Update CG URLs Update introduction Update technical-report-descrip… and 1 more (compare)

  • Feb 03 11:13

    csarven on main

    Add Solid QA (#495) * Add Soli… (compare)

  • Feb 03 11:13

    csarven on qa

    (compare)

  • Feb 03 11:13
    csarven closed #495
  • Feb 03 11:13
    csarven commented #495
  • Feb 03 11:00
    csarven synchronize #495
  • Feb 03 11:00

    csarven on qa

    Update abstract in response to … (compare)

  • Feb 02 16:14
    csarven commented #498
  • Feb 02 16:14

    csarven on main

    Add 2023-02-01 agenda and minut… (compare)

  • Feb 02 16:14

    csarven on 2023-02-01

    (compare)

  • Feb 02 16:14
    csarven closed #498
  • Feb 02 11:42

    csarven on main

    Update some links to the redire… (compare)

  • Feb 02 11:22

    csarven on main

    Update societal-impact-review s… (compare)

  • Feb 02 10:41
    csarven synchronize #498
  • Feb 02 10:41

    csarven on 2023-02-01

    Add clarifications to 2023-02-0… (compare)

  • Feb 02 10:12

    csarven on 2023-02-01

    Apply suggestions from code rev… (compare)

Sarven Capadisli
@csarven

@uvdsl Excellent. I've just moved Henry's issue from 2015 to solid/notifications#35 . Please do share your findings in that issue (and elsewhere in that repository).

The current work on notifications (protocol / data model..) is taken on by the https://github.com/solid/notifications-panel (see Charter: https://github.com/solid/process/blob/main/notifications-panel-charter.md ) . Chat: https://gitter.im/solid/notifications-panel . You're invited to join us on Thursday meetings.

1 reply
sjoertrix
@sjoertrix:utwente.io
[m]
Sounds like a bridge between Solid PubSub and WebPush. Maybe related info here: https://github.com/solid/solid-spec/blob/master/api-websockets.md
Christoph Braun
@uvdsl
Yes, actually I was thinking of a work around like that (maybe that is in fact the a possible solution).
(Could also be a non-solid but additional service that a pod provider could offer (or any other service provider))
If I have some spare time on the weekend, I will try to code up a little demo.
Sarven Capadisli
@csarven

There are no restrictions on methods. CHICKEN is perfectly acceptable (and not a misspelling of CHECKIN).

<3

Randy Le
@dynamoRando
Hi all. I have an open solid/solidproject.org#672 in the solidproject.org repo to make a reference to the current solid specs. Could someone please inform me if these are the correct links: https://github.com/solid/solid#standards-used and https://github.com/solid/solid-spec, or should I instead refer to https://github.com/solid/solid-spec/tree/v0.7.0?
Aaron Coburn
@acoburn
The URL for the Solid Protocol specification is https://solidproject.org/TR/protocol (not solid-spec)
2 replies
Sarven Capadisli
@csarven
I've been closing issues in the older repos and transferring them to relevant active repos when necessary. If the repo is archived, we can't transfer issues - will need to unarchive first. Having said that, we can do the following:
  • Process open issues. If within scope/roadmap, transfer to relevant repository.
  • Update READMEs
  • Archive repo.
6 replies
Fred Gibson
@gibsonf1
Are there any ontology standards for delivering messages to solid users inbox?
elf Pavlik
@elf-pavlik
I don't know, but IMO inboxes should have at least some best-practices document. For example, public inboxes can be targeted by spam. I would never put a public inbox on storage that has anything else on it except that inbox. Probably I would also use storage from a dedicated public inboxes provider who has additional measures in place to deal with unavoidable spam.
Fred Gibson
@gibsonf1
I guess one easy way to reduce spam is make the inbox append for authenticated agent only
Sarven Capadisli
@csarven
@gibsonf1 https://www.w3.org/TR/activitystreams-vocabulary/ is a great fit and already used by some Solid applications.
Pete Edwards
@edwardsph
Re http-https redirects, should this requirement (https://solidproject.org/ED/protocol#server-tls-https-redirect) be changed to allow 301 or 308 in order to take account of non-GET requests. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections#permanent_redirections?
Sarven Capadisli
@csarven
See also Constraints, AS2, Authenticated Inboxes under https://www.w3.org/TR/ldn/#security-privacy-and-content-considerations
Sarven Capadisli
@csarven
There is nothing different about a public-append inbox and any resource.
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)