Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 17 14:48
    csarven synchronize #417
  • Aug 17 14:48

    csarven on 2022

    Apply suggestions from code rev… (compare)

  • Aug 17 14:44

    csarven on main

    Add 2022-08-17 minutes (compare)

  • Aug 17 14:10
    csarven synchronize #417
  • Aug 17 14:10

    csarven on 2022

    Update doad:revision to 1.0.0-c… (compare)

  • Aug 17 12:48

    csarven on main

    Update current copyright year (compare)

  • Aug 17 08:10

    csarven on main

    Add guideline for 'citation nee… (compare)

  • Aug 15 18:01
    almereyda commented #448
  • Aug 15 13:17
    csarven closed #448
  • Aug 15 13:17
    csarven commented #448
  • Aug 15 12:55
    csarven commented #409
  • Aug 15 12:54
    csarven commented #409
  • Aug 15 12:54
    csarven closed #409
  • Aug 15 12:54

    csarven on main

    Add requirement for Solid Notif… Adjust version reference Update ED/protocol.html Co-aut… and 2 more (compare)

  • Aug 09 01:05
    elf-pavlik commented #447
  • Aug 08 15:22
    TallTed commented #447
  • Aug 07 02:14
    almereyda opened #448
  • Aug 06 09:58
    melvincarvalho commented #447
  • Aug 06 09:55
    melvincarvalho commented #447
  • Aug 06 09:44
    melvincarvalho commented #447
Henry Story
@bblfish
yes, ontologies should be available via GET if well designed. But PLEASE build caching systems
Emmet
@emmettownsend
I think it will be necessarily to have a few standard endpoints. However rather than hard code them we should think about using something like a .well-known/solid endpoint where a client can discover the endpoints supported by a server.
Henry Story
@bblfish
The whole notion of "endpoint" smaks somehow of SOAP, so I tend to think one should avoid it.
Emmet
@emmettownsend
:)
for example . a registration endpoint.
Henry Story
@bblfish
registration for what?
Emmet
@emmettownsend
allows the creation of pods without requiring a user and a browser. and makes it standard across servers.
Search is anothers example
certainly not anythng like SOAP though
Henry Story
@bblfish
That sounds a bit like an index...
Emmet
@emmettownsend
index is just an implementation detail
its really about discovery
how do I create a pod on this service.
how do I search on this service
Henry Story
@bblfish
I think containers and resources should provide their own query link...
Emmet
@emmettownsend
ok so providing a link header to allow a client discovver how it queries a container is certainly one way. But we also need to think about cross pod searches and corss ecosystem searches
similarly one could have a link header from a server to discover the pod resistration end point.
Some of these things will not change and there may be push back around adding lots of link headers. Hence another approach would be a .well-known/solid resource
This could be available per pod and per server
Henry Story
@bblfish
Hmm. I don't have that much of an opinion on that yet.
Emmet
@emmettownsend
from my perspective there are many ways to approach it. But things like this should be in the spec in order to ensure interoperability and portabililty
Sarven Capadisli
@csarven
Solid resources are intended to be self-describing. No need for .well-known/solid when the Storage resource (root container) can link to what it has.
Emmet
@emmettownsend
That is only true while there is no problem with link hearder tax
and we would still need to align on the terms to use to access specific services.
Sarven Capadisli
@csarven
Will have to do that any way.
Emmet
@emmettownsend
So there are really two things 1) What standard services must/may be provided and what terms should we use 2) How do we approach discoverability for these, becuase its not a given that it should always be a link header
Sarven Capadisli
@csarven
There are existing stuff like VoID or SPARQL Service Descriptions.
VoID indeed has .well-known/void
(which I hate)
but have used it extensively
Emmet
@emmettownsend
The implementations are already beginning to needs this so we should make decisions soon on thise to help maintain interoperabillitiy
For example ESS is already looking exposing registration and search
Sarven Capadisli
@csarven
Identity?
Emmet
@emmettownsend
?
Sarven Capadisli
@csarven
Registration of what?
Emmet
@emmettownsend
registration of a pod.
so pod creation
which should be decoupled from identity. identity creation is a different thing
Sarven Capadisli
@csarven
I thought we had more issues related to this... I'm sure they're around.
Emmet
@emmettownsend
Oh there are certainly issues. But we are now at the point where we need to resolve them. :)
Registration of an identity, registration of a pod, > 1 Pod per identity, moving a pod to another provider, changing owner of a Pod, making sure no links are broken. There are all related.
and of course bringing ones own domain for a webid and for a pod
Henry Story
@bblfish
Btw. I think that my Http Sig Authentication proposal is starting to look good. It brings in a lot of elements from the Self Sovereign Identity (DID, Universal Wallets, Agents, Verifiable Credentials, Signing HTTP Messages, ...) and so I think it could be a good thing to discuss with the Credentials folks in March. It also work very nicely with ACP/WAC. It is also I think optimally efficient.
Emmet
@emmettownsend
@bblfish thanks for the heads up. I haven't been keeping up to date so will have a read of it tonight. Cheers
Henry Story
@bblfish
If something is unclear let me know with a comment or such. :-)
I am going to be in programming mode for the next week or so: I need to get a basic LDP server together.
Emmet
@emmettownsend
Will do.
Sarven Capadisli
@csarven
Meeting with the WICG on identity+authentication is confirmed: https://github.com/WICG/WebID/issues/54#issuecomment-779405599
Sarven Capadisli
@csarven
@gibsonf1 Is your server publicly accessible?
Fred Gibson
@gibsonf1
@csarven Yes, but we will wipe the db before official launch at Solid World, so it is not in production mode yet