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)

Emmet
@emmettownsend
and we would like to get all that code working with Solid some day
Sarven Capadisli
@csarven
Some generic applications ie. the ones allowing users to upload any format and unable to set the Content-Type.
Emmet
@emmettownsend
not necessarily unable - just didnt or sloppy or didnt know or didnt do it and ti jsut worked. whatever
Sarven Capadisli
@csarven
So what's preventing them from sending the Content-Type?
Emmet
@emmettownsend
nothing.
how many of those millions of developers will go and update their code or even know that is the problem when it doesnt work in a solid world?
It fundamentally breaks backward compatibility with HTTP
Sarven Capadisli
@csarven
This was a design decision that was deemed to be "clean and safe" for the Solid ecosystem.
Emmet
@emmettownsend
I get it. I just disagree and believe it is flawed reasoning
of course its cleaner and safer. But I dont thnk that is the point or the main concern. Surly we need to head for ubiquity.
Sarven Capadisli
@csarven
I hear you.
Different ways to look at this.
Should Solid clients know what they are sending .. where a server has some degree of trust on what it is (regardless of sniffing/processing)
Emmet
@emmettownsend
should solid be compatible with HTTP
Sarven Capadisli
@csarven
I don't see how it isn't. It has a stricter requirement
Emmet
@emmettownsend
whihch will break code for milllions of developers
and be a barrier to adoption
Sarven Capadisli
@csarven
Neither does it mean that there is no room for wilful violation, if it came down to it.
Does podbrowser send a valid field-value for Content-Type or it doesn't send the header at all?
Emmet
@emmettownsend
There was a case where it didn't . This is how I discovred this change to HTTP. One of the team members pointed out that a particular file upload failed and then discovred why.
So of course we will update that code. But.......that discovery led me to reading the spec and coming to the conculsion that I have come to. Hence raising the convern here and raising the issue
Sarven Capadisli
@csarven
If some specific aspect wasn't already covered (maybe details escape me right now) or discussed in depth in solid/specification#70 , comment there perhaps for the record. Maybe nudge Tim as well :)
Thanks for bring this up (in public) by the way!
This is less of a concern for PATCH requests because there really is a no go at the moment besides application/sparql-update
Emmet
@emmettownsend
true. But most write requests in existinng code are likely to be POST
PUT has likely increased in recent years but I dont have stats to back that up.
Sarven Capadisli
@csarven
I would suspect that most POSTs on the Web are via HTML Forms in which the server processes. But yea, can't see how we'd get any stats on this.. ie. whether clients are generating a Content-Type with a valid field-value (regardless of the media type) in case where they don't actually know the format. So like text/plain or application/octet-stream at least.
Martynas Jusevicius
@namedgraph_twitter
so what happens if the client sends a request with RDF body and without Content-Type?
Emmet
@emmettownsend
according to the spec an error
according to http, the server could either inspect the content to determine the type, or could treat it an an octet-stream or could respond with an error
Sarven Capadisli
@csarven

Right but there is this:

In practice, resource owners do not always properly configure their
origin server to provide the correct Content-Type for a given
representation, with the result that some clients will examine a
payload's content and override the specified type. Clients that do
so risk drawing incorrect conclusions, which might expose additional
security risks (e.g., "privilege escalation"). Furthermore, it is
impossible to determine the sender's intent by examining the data
format: many data formats match multiple media types that differ only
in processing semantics. Implementers are encouraged to provide a
means of disabling such "content sniffing" when it is used.

Emmet
@emmettownsend
yup. But we cant turn back the clock
We can ensure we have a secure server.
Tim Berners-Lee
@timbl
You started an issue about this at solid/specification#211 pp lets discuss it there
Sharon Stratsianis
@SharonStrats
Hi @csarven just wanted to double check with you are there any specifications currently regarding location information?
Sarven Capadisli
@csarven
@SharonStrats Can you elaborate on what you are looking for? Protocols, data models.. ? GPS? Geolocation API? .. We (re Solid) don't have anything on "location information" but there's stuff out there. I suspect you want something more than http://www.w3.org/2003/01/geo/wgs84_pos ?
10 replies
cniekel
@cniekel
Hi.. Hope this question is acceptable here, feel free to send me elsewhere. I was reading the specs, I didn't see anything that would be like 'dns redirects'. For my email (and my jabber) I really like that for mydomain.org I can choose which company handles my email (via MX records) and for jabber via _xmpp txt records. Is something similar planned for solid? I'd like to be able to switch pod-providers without changing my web-id (or change what server software I run with some graceful conversion. Is that planned?
Emmet
@emmettownsend
Hi @cniekel. I can tell you some of the things we are thinking about at Inrupt. I am working with the authorization panel but not the rest of the panels at the moment so this answer is not meant to be on behalf of the spec team. So you will be able to have multiple Pods associated wtih one identity. You will also be able to move Pod providers seemlessly. We would like to get to a point where you can also move providers without any links breaking. That requires 2 things. 1 - The identity uses a domain you control 2 - The Pod provider allows you to use then enture path after the domain i.e. from /. I'm sure people on the spec team will likely chime in with where the spec is at the moment with respect to those questions. I know there is the concept of pim:storage already which allows you to specify where the storage is located. Hope that helps but happy to respond to any followup questions.
cniekel
@cniekel
That sounds really good. Thanks!
Sarven Capadisli
@csarven
@cniekel You can continue to do all those things as long as you hang on to your domain name. Solid is described on the HTTP layer.
Tim Berners-Lee
@timbl
@cniekel Yes being able to switch the hosting of your own domain is a much wanted thing. It’s in the solid roadmap.
Tim Berners-Lee
@timbl
Well - I thought it was! Just added it to the Roadmap as Bring your own DNS Domain
Yvo Brevoort
@ylebre

crossed over from solid/chat to here:

We're having a discussion about pod migration (like what we needed when solid.community went offline) - would it be correct to assume that if I were to migrate my storage pod to another location, I could send out a 301 Permanent redirect for that URI?

In the spec I can find some things about leaving a tombstone (410 Gone) - would it be reasonable to expect a previous location to also keep track of where a resource has moved to?

Any pointers to more information would be appreciated!

The scenario we're thinking is mostly about moving from one storage provider to another, while both providers are still available - if the DNS record disappears there isn't much we can do about it I suppose
Instead of leaving a set of 410 Gone results on the old location, it could do a 301 Permanent redirect to the new location instead - but this would require the old location to know where to send those requests.
Yvo Brevoort
@ylebre
And, how would a mechanism work - should resources pointing to the old location update to the new location if it is a permanent redirect?
Sarven Capadisli
@csarven
@ylebre Do you and @cniekel collaborate? As mentioned earlier in this chat and in solid/chat, while URI Ownership and Persistence are important to Solid, domain name control and DNS record maintenance is orthogonal ie. Solid is described on the HTTP layer. We can however provide guidance on pod migration and possibly spec an API on how to move resources (while keeping existing identifiers). See for example: https://solidos.solidcommunity.net/public/Roadmap/Tasks/state.ttl#Iss1606741599846 , among other htings.
You would only need to redirect if URIs change. 410 is not relevant unless you want to put domain A's resources to rest. No chance to redirect in that case if you want to continue from domain B. As noted, changing domains (with or without control of the first) is costly. Breaks referencing / redirect maintenance tax.
Sarven Capadisli
@csarven

@/all Solid meetings are using different video conferencing tools/services. They are controlled by different parties. No single party needs to control, start/end meetings or require proprietary tooling to be installed on desktop or run in the browser. We can simplify and keep things neutral - as much as we reasonably can - for the W3C Solid Community Group.

Fortunately, there are already have open source tool/platform/service options eg. Jitsi. I suggest for all spec / panel meetings to happen at:

If anyone would like to raise an objection, please share your preferences or expectations.

(Plenty of other Jitsi instances to choose from: https://jitsi.github.io/handbook/docs/community-instances . We could - although this is a lot more work - even host our own at meet.solidcommunity.net or something but that's probably a bit far down the road.)