solid/specification

Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct

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).

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.

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)

Where communities thrive

People

Repo info

Activity