Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 14 09:42
    KMax closed #66
  • Jun 14 09:42
    KMax commented #66
  • Jun 14 09:29
    csarven commented #66
  • Jun 14 09:25
    KMax commented #66
  • Jun 14 09:19
    csarven commented #66
  • Jun 14 09:16
    KMax starred w3c/ldn
  • Jun 14 09:16
    KMax opened #66
  • May 28 09:46
    ertugerata starred w3c/ldn
  • May 14 21:37
    QuantumCloudDatabase starred w3c/ldn
  • Apr 17 19:39
    salifm starred w3c/ldn
  • Mar 05 16:44

    plehegar on master

    Boilerplate files (compare)

  • Mar 05 14:51
    AntoniaWild starred w3c/ldn
  • Feb 03 17:03
  • Dec 04 2018 11:49

    csarven on master

    Remove unused CSS/JS in ED Change spacing from 4 to 2 (compare)

  • Oct 05 2018 07:02
    taurenshaman starred w3c/ldn
  • May 22 2018 03:15
    BlackGlory starred w3c/ldn
  • May 11 2018 19:16
    js-choi starred w3c/ldn
  • Mar 21 2018 14:59
    luismendes070 starred w3c/ldn
  • Mar 04 2018 17:20
    Visgean starred w3c/ldn
Amy Guy
@rhiaro
And it's the easiest to understand case. The # thing is special case that SW people will understand but nobody else will even think of
Sarven Capadisli
@csarven
That's fine.
Amy Guy
@rhiaro
And # people aren't restricted in any way from using body
So should all be good
Sarven Capadisli
@csarven
I'm looking at it broader.. discovery is not only through HTTP requests.. but could be queried for in an RDF store.
Alright.
So, now.. we just have to resolve the serialisation issue?
Amy Guy
@rhiaro
We're not speccing discovery by query though are we?
Sarven Capadisli
@csarven
  1. the resource body that announces its inboxes
  1. the inbox uri
  1. the notification uri
We are not.
Perhaps this is all fine. We established that everyone can be happy if the HEAD or GET can be utilised to find inboxes
Aside: I've tested LDN spec on Mac Firefox/Chrome, it didn't show the notification for some reason. Okay on Ubuntu. I'll have to look again when I get a chance. I recall it not working on your Ubuntu Mint Chrome either..
Amy Guy
@rhiaro
I'm still uneasy about senders being required to parse rdf to discover but that's a different conversation.
There's no such thing as Ubuntu mint
:p Also I use kubuntu not mint
Sarven Capadisli
@csarven
Whatever OS you were using on your laptop on Friday.
Sorry, I thoguht it was Mint.
Everyone can speak only JSON-LD, and that's fine, we can stop at that.. but that means discovery of inboxes in other serialisations (e.g., HTML+RDFa in dokieli) .. unless the server can send an JSON-LD serialisation of it.
Am I missing somehting?
Sarven Capadisli
@csarven
@rhiaro csarven/ldn@3586fd6
The original was a little confusing and it also implied that HEAD came first and if no good try GET. So, I updated to clarify that either can be done, and the order doesn't matter.
Sarven Capadisli
@csarven
Should it say 'either or both' ?
Amy Guy
@rhiaro
For some reason I thought the order does matter, head should be done first. We shouldn't be encouraging parsing the full body if not necessary, bad practice and also an attack vector we need to mention in security section. Also sender MUST be able to do both! (Only stop if inbox found, not only try one then stop). I feel like order matters so the publisher knows what's going to happen reliably.
Sarven Capadisli
@csarven
Well.. it is not 'bad practice' especially when the HEAD can only give you an inbox of the doc. We agreed that they are both useful. I can go along with HEAD being first, but then I'd like an explicit mention of an exclusive either of the approaches: if HEAD/Link has inbox, stop. otherwise, GET the body and find the inbox. Don't put inbox in HEAD/LInk and in GET. Pick one.
Amy Guy
@rhiaro
I agree.
I thought that was obvious, but if it's not, then add it in
wait what you said is slightly confusing. "if HEAD/Link has inbox, stop." otherwise, GET the body and find the inbox." == instructions for sender. "Don't put inbox in HEAD/LInk and in GET. " == instructions for receiver
I don't think it matters whether or not the receiver puts it in both (maybe they use it for something else in body) but the sender/consumer must stop after head if they find it there
That should be clear for the receiver that if they put it in both, the head is what counts
Sarven Capadisli
@csarven
Sure, but it is possible to look at the body only for the consumer. if dokieli loads an article (its body is available to js) it can look to see if there is an inbox in the body right away.. it doesn't have to do a HEAD. If it doesn't find it, it can look at HEAD if it wants.
Unless you really want to force that no matter what, do a HEAD first.
Amy Guy
@rhiaro
I guess, I forget javascript.
I feel like mostly messages are going to be sent to resources that aren't the current one loaded, but what do I know
Maybe order doesn't matter
but it's not like head is expensive
I suppose try one then MUST try the other if not found is fine, in either order
Sarven Capadisli
@csarven
I think it should be at the discretion of the discoverer, no? They can have good reasons to try either or both.
Amy Guy
@rhiaro
Yeah you're probably right
Amy Guy
@rhiaro
Ooh what if for AP all we need to do is say advertise application/activity+json in the Accept-Post header, and everything is good?
But ldp:contains would still need to be replaced with as:items for consuming
Sarven Capadisli
@csarven
Lets talk about that serialisations tomorrow and wrap that up
easy stuff :P
Amy Guy
@rhiaro
Errol is updated https://apps.rhiaro.co.uk/errol/ but only AS2 works right now
So you can put http://rhiaro.co.uk in the 'to' field and fill in whatever else you want and I'll get it
My server messes up the id of the notification though, need to fix that..
You can send, then reload http://rhiaro.co.uk/ldn.php (for ldp:contains JSON, or rhiaro.co.uk/inbox/ for a file listing) to see it
spam ahoy!
Sandro Hawke
@sandhawke
Actuallyu doing annotation: