Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:25
    csarven synchronize #489
  • 15:25

    csarven on 2022-12-07

    Minor (compare)

  • 15:00
    csarven synchronize #489
  • 15:00

    csarven on 2022-12-07

    Update 2022-12-07 minutes (compare)

  • 10:51
    tomhgmns commented #487
  • 10:46
    tomhgmns commented #487
  • 10:46
    tomhgmns commented #487
  • Dec 06 16:06
    csarven synchronize #489
  • Dec 06 16:06

    csarven on 2022-12-07

    Apply suggestions from code rev… (compare)

  • Dec 06 15:05
    csarven labeled #489
  • Dec 06 15:05
    csarven opened #489
  • Dec 06 15:05
    csarven assigned #489
  • Dec 06 15:05
    csarven edited #488
  • Dec 06 15:04

    csarven on 2022-12-07

    Add 2022-12-07 agenda and minut… (compare)

  • Dec 06 15:00

    csarven on main

    Add links to calendar and meeti… (compare)

  • Dec 06 14:02
    csarven commented #453
  • Dec 06 11:51

    csarven on main

    Minor (compare)

  • Dec 06 11:50

    csarven on main

    Add guideline for acknowledging… (compare)

  • Dec 05 11:58
    csarven commented #290
  • Dec 05 11:45
    csarven assigned #290
Sarven Capadisli
@csarven
? Why can't applications GET the vocabs/ontologies from source? What's the use case?
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?