Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:58
    csarven labeled #499
  • 08:58
    csarven assigned #499
  • 08:58
    csarven opened #499
  • 08:57

    csarven on 2023-02-08

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

  • Feb 07 21:35
    csarven edited #491
  • Feb 07 21:32
    csarven synchronize #491
  • Feb 07 21:32

    csarven on 2022

    Add TR/2022/notifications-proto… (compare)

  • Feb 07 21:07
    csarven edited #492
  • Feb 07 21:03
    csarven edited #492
  • Feb 07 20:16
    csarven synchronize #492
  • Feb 07 20:16

    csarven on 2022

    Add TR/2022/protocol-20221231 (compare)

  • Feb 07 20:11

    csarven on main

    Minor (compare)

  • Feb 07 20:02

    csarven on main

    Minor (compare)

  • Feb 07 19:54

    csarven on main

    Minor (compare)

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

sjoertrix
@sjoertrix:utwente.io
[m]
@kjetilk: We have update our specification with an update to clarify Auxiliary Description Resource. Is this in line with your thoughts on this?
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).

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