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

sjoertrix

@sjoertrix:utwente.io

[m]

See: https://pdsinterop.org//solid-link-metadata/solid-storage-specification/#lm-auxiliary-description-resource

kjetilk @kjetilk looks

Sarven Capadisli

@csarven

Consider changing language like "you" to whatever actor is intended e.g., server.

Kjetil Kjernsmo

@kjetilk

@sjoertrix:utwente.io Yes, that's an improvement! I still think we need to define a separate aux resource type for it, since this one will be deleted when the subject resource is deleted

Sarven Capadisli

@csarven

(actor in the general sense.. the thing with specifics role(s))

s/LINK/Link

There is/was a propose LINK method. All uppercase can be confusing for an HTTP header.

sjoertrix

@sjoertrix:utwente.io

[m]

Thank you @csarven, changed LINK -> Link and a number of you have been changed to actors to make it more clear.

The source is here: https://github.com/pdsinterop/solid-link-metadata/tree/main/solid-storage-specification, feel free to propose changes. Really appreciated as we hope to create something useful with the ontology and specification.

Jeff Zucker

@jeff-zucker

@SharonStrats - I can give my phone number to many people but as long as I am in possession of my phone, they can only use that number to call me. Same with a WebID - I might have multiple IdPs able to verify that I am me (by allowing me to login), but all of those IdPs will still be pointing to my one WebID document at the WebID URI. I can change or drop IdPs at any time. If and when there is a preferered IdP that will only impact apps that visit my WebID document knowing which IdP to contact. The relationship with the IdP would not change at all, only how the app finds the IdP.

5 replies

Jeff Zucker

@jeff-zucker

I can also have multiple WebIDs, but that 's a different case, above applies to one WebID with multiple IdPs.

Sarven Capadisli

@csarven

I tried a bunch of tools to copy labels from one repo to another repo in the same organisation but didn't succeed. Can't tell if the tools are a bit outdated/broken or if I did something wrong. I'll check it out again some other time. If anyone recently had success with a tool, please let me know which.

1 reply

Christoph Braun

@uvdsl

Hi all,
I am building a Progressive Web App (PWA) where I would like the user to get notified when she receives a new LDN, i.e. when a new resource is created in her inbox.
I looked into the websocket support [1], which worked great in a little utility demo web app [2].
However, for that to work, the app needs to be open.
When a user installs my PWA on her phone, the app is not able to notify the user about new LDNs (since the websocket connection is closed).
But that is where the PWA's service worker and its ability to receive Web Push Notifications [3,4,5] come in.
With Web Push Notifications, the PWA would be able to notify the user even when closed by receiving a push notification from the server (i.e. possibly the Pod?).
Has there already been a discussion about Web Push being a part of Solid Pods or Solid in general?
Cheers
Christoph

[1] https://github.com/solid/solid-spec/blob/master/api-websockets.md
[2] https://github.com/uvdsl/solid-inbox-watcher
[3] https://datatracker.ietf.org/doc/html/draft-ietf-webpush-protocol
[4] https://developers.google.com/web/ilt/pwa/introduction-to-push-notifications
[5] https://www.youtube.com/watch?v=2zHqTjyfIY8 (coding demo)

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

Where communities thrive

People

Repo info

Activity