Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 01 13:57
    elf-pavlik commented #227
  • Oct 01 13:55
    elf-pavlik commented #227
  • Oct 01 13:54
    elf-pavlik commented #227
  • Sep 30 22:58
    elf-pavlik commented #291
  • Sep 30 13:05
    elf-pavlik commented #458
  • Sep 30 12:59
    elf-pavlik commented #457
  • Sep 30 11:32
    csarven transferred #460
  • Sep 30 10:12
    michielbdejong opened #460
  • Sep 30 08:08
    michielbdejong commented #457
  • Sep 29 18:34
    csarven commented #279
  • Sep 29 18:22
    csarven commented #279
  • Sep 29 18:19
    elf-pavlik commented #279
  • Sep 29 18:14
    csarven closed #459
  • Sep 29 18:14
    csarven commented #459
  • Sep 29 18:00
    elf-pavlik edited #459
  • Sep 29 18:00
    elf-pavlik opened #459
  • Sep 29 17:23
    jaxoncreed commented #457
  • Sep 29 15:41
    TallTed commented #458
  • Sep 29 13:24
    csarven opened #458
  • Sep 29 13:23

    csarven on w3c-solid-cg-weekly

    Add W3C Solid CG weekly meeting… (compare)

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

Yvo Brevoort
@ylebre
@csarven not collaborating with @cniekel yet :) What we are thinking is in the lines of, what if I wanted to move my solid storage pod from a US-based service into a EU-based service. The URIs would need to move from solid.us to solid.eu somehow. The 410 (specifically, a tombstone for a resource that is no longer there) came to mind because it would require the old location to know that a resource used to exist on that location. That same thing could be used to know that a resource has a new location to trigger a redirect.
Sarven Capadisli
@csarven
If you control solid.us and solid.eu, then definitely redirect.
Assuming you want continuous operation. Without the redirect, people obviously can't find the new location.
csarven @csarven pokes @dmitrizagidulin
Henry Story
@bblfish
Is this the right way to write this WAC-Allow: user="read,append,write" ?
If I got it wrong, let me know here. I'll fix it up in this issue solid/authorization-panel#141
Jeff Zucker
@jeff-zucker
AFAIK, yes user="read append write",public="read"
Henry Story
@bblfish
ok cool
Jeff Zucker
@jeff-zucker
This message was deleted
3 replies
Oops one sec
No commas inside the quote, this is correct : user="read write append control",public="read"
1 reply
Emmet
@emmettownsend
just had a read
interesting.....
the Agent is allowed the access modes.
the Policy allows the access modes
the Resource allows the access modes (kind of. as far as the client is concerned)
If we were to translate to triples the way you sugggest then the last one would be correct and the domain would be a resource??
Henry Story
@bblfish
The usage in a Link header seems to suggest that. But if you have a direct link to the mode, then you are missing which agent is allowed.
Jeff Zucker
@jeff-zucker
So there is an implied relationship, something like "Resource regulatedBy Policy"?
2 replies
Emmet
@emmettownsend
So the link header pertains to the agent who made the request
Jeff Zucker
@jeff-zucker
For describedBy and acl relationships, it's the resource that is the subject.
Emmet
@emmettownsend
I think perhaps we need to change the domain for acp:allow to resource rather than policy
Henry Story
@bblfish
@emmettownsend I guess the thing is that you are not just using acp:allows in Link headers. You are also using it in the ACP Document, where it makes sense to have it be related to a acp:AccessPolicy
Emmet
@emmettownsend
mmmmmmmmm yes
in that case perhaps we need another term.
because the domain is definitely Policy when used in the other case.
Jeff Zucker
@jeff-zucker
The pretty picture in the ACP Document shows the relationship acp:accessControl between a Resource and it's AcessControl Resource, but no relationship names for what's between the Resource and its Rules and Policies
Emmet
@emmettownsend
hold on I'll have a look
oh the first diagram.
if you keep reading it builds it up piece by piece until the full diagram is constructed
Jeff Zucker
@jeff-zucker
Very nice, thanks. Exactly what I was looking for.
Michiel de Jong
@michielbdejong
Just read an interesting quote from Oz: "Notes On Compatibility
If you have an existing application that was built against the Node Solid Server it is likely that changes will need to be made to the application in order to work with the Enterprise Solid Server. This is due to the latest changes in the spec not being reflected in the Node Solid Server. " - can you comment on that @csarven?