🔔 Linked Data Notifications
Home Page: https://www.w3.org/TR/ldn/
Raised by @sandhawke
Should the spec include actions taken on notifications e.g., notification getting marked as 'read'?
Hi,
In the example for "Discovering an Inbox with a GET request to retrieve HTML."
Currentlym this is used:
<a href="/inbox/" rel="http://www.w3.org/ns/ldp#inbox">My inbox</a>
I was expecting that in HTML, the discovery of the inbox would be done from the header of the html with a link element. Something like:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>A home-page</title>
<link href="/inbox/" rel="http://www.w3.org/ns/ldp#inbox" />
</head>
<body>...</body>
</html>
An element would display the link for human users, which may happen to be desired in some cases, but I would not expect it to be frequent.
Something along these lines:
The LDP specification requires supporting Turtle and JSON-LD while the LDN specification only requires supporting JSON-LD. This implies that an implementation of LDN which is also conforming to LDP MUST support both JSON-LD and Turtle.
Should it be possible to discover domain specific inboxes. Can implementations around generic and specific inboxes be interoperable?
Is there an actual use-case where the generic sender needs to find the specialised inbox and send to it, and similarly receiver to handle that scenario?
[There is a branch which covers the domain specific vocabulary:
https://github.com/csarven/ldn/tree/extended-discovery - this was part of the master branch but removed there until further discussion]
sent on behalf of Felix Sasaki
https://www.w3.org/TR/ldn/
non i18n comment: the draft refers to an IETF draft which has expired: https://tools.ietf.org/html/draft-wilde-accept-post-03 and seems not to be worked on. The WG should consider updating or dropping the reference.
Should receivers and/or consumers be required to dedup identical notifications so the user doesn't see them twice?
eg. If I'm using a client that creates a post for me that mentions Alice (eg. via micropub/activitypub) and the client also sends notifications to Alice's inbox, but unbeknownst to the client my micro/activitypub endpoint also sends inbox notifications to people mentioned upon new post creates, Alice will get the same notification twice. The bodies might be different if the client and my server decide to make slightly different json blobs, but there might be some fields with ids in that can be used for deduplicating.
This is way harder with arbitrary payload. Client might actually send a completely different notification to Alice than my server does.
Raised by @rtroncy
Similar to w3c/webmention#48, how many times should a Sender/Consumer that wants to do discovery several times on one resource, or multiple target resources on the same domain, try to find the inbox endpoint before it gives up? To avoid knocking over a server, or being blocked for too many GET requests?
Do we need a SHOULD on retrying failed send attempts?
PuSH says:
Hubs SHOULD retry notifications repeatedly until successful (up to some reasonable maximum over a reasonable time period)
Which is suppose is saying its an implementation detail how you do it, but you should really think about doing it.
Senders may send OPTIONS requests to receivers. In section 3.2:
The sender may use an OPTIONS request to determine the RDF content types accepted by the server, and serialize the notification in the request body according to the value of the Accept-Post header [Accept-Post] returned.
The OPTIONS request is not mentioned in section 3.3 about the receiver. The Accept-post header is mentioned, but not the OPTIONS request in particular. Could mean that the Accept-post may only be supported in the POST responses of the receiver?
Maybe this is useful in an implementation section; at least worth thinking about
On a quick scan of the spec, I'm not seeing any way for consumers too receive notifications asynchronously which, in my perspective, would be the whole point of "notification"s.
What I do see is a queueing mechanism that allows one party to queue information packets, and another to retrieve them when they're ready.
Maybe this is fine and useful, but if so I guess I'd suggest the spec may be misnamed.
One area which might need further explanation is what happens when the sender gives Turtle, receiver creates Turtle, but the Consumer asks for JSON-LD. Some options:
Should the spec include how to update notifications e.g., delete, update? Out of scope? Depends on data model?
[sent on behalf of Addison Phillips]
There is no use of the Content-Language or Accept-Language HTTP headers as a means of possibly negotiating language. Should there be?
make an HTTP GET request on the target URL and, for RDF sources [RDF 1.1], the Inbox is the object of the predicate http://www.w3.org/ns/ldp#inbox.
This and the previous bullet point seem to be saying
look at the header or the body for a link to the inbox.
The second bullet point is missing a reference to the returned "representation" and its semantics, so that it is not clear what is going on.
Under Section A of the draft spec, the schema prefix uses a namespace with a https scheme. Also, in the index.html document, the https scheme is used, but in schema.org's documentation (and elsewhere in the LDN documentation) the plain http scheme is used. I believe that the plain http scheme is the correct one, i.e. http://schema.org/.
I'm concerned about this:
Upon receipt of a POST request to the Inbox, the receiver must create a new resource containing the RDF data from the body of the POST request and must return HTTP 201 Created with a Location header pointing to the created resource.
The problem is that this sentence requires that the receiver store invalid / spam / etc notifications. With my experience from receiving Pingbacks, the vast majority of requests my endpoint received were spam. In this case, you're basically asking an implementer to store junk notifications as well.
I'd suggest allowing the receiver to not store unverified notifications. Since you already have a section about what a verified notification means you can reference that. https://linkedresearch.org/ldn/#sender-verification
Raised by @sandhawke
Multiple resources MAY use the same Inbox; one resource MAY have multiple Inbox URLs.
In this case, when I do a GET on a Resource's inbox, I may GET notifications from a million other Resource's inbox, and I wont be able to tell. That seems awkward.
Re.
The sender determines the target for a notification based on its own requirements; once determined, the sender discovers the location to send it to (the Inbox) from the target itself.
A lot of pronouns are used here which doesn't make this sentence easy to read:
If we want this to work with ActivityPub/Sub we need to support AS2 properly by requiring receivers to apply the default @context to any plain JSON posted with this media type, and then treating as JSON-LD.
And also we'd need to allow consumers to request application/activity+json and receivers must treat it the same as ld+json when returning data to AP/S consumers; I thiiiink a regular JSON-LD payload should be fine for plain-JSON AS2 consumers so long as the Content-Type is activity+json in this case (ie. they'd just ignore the @context, but it would also need to be guaranteed in the compact(??) syntax).
This diverges from plain LDP, but maybe that's okay..
the 20160926 version does acknowledge that having a server tell one where to post to does pose a security risk in the loopback note in 3.2, but does refer to that in the security considerations section.
furthermore, it is my impression that the loopback criterion is insufficient: resources exclusively protected by origin policies could be present anywhere inside a link-local, vpn or firewalled network. have other means of protection been explored? first thing that comes to my mind would be a pre-flight OPTIONS that checks for an "i'm an inbox" indicator, especially given that for anything but application/ld+json payload, such a pre-flight request is mandatory anyway.
Moving issue from #6
If multiple Inboxes are discovered, senders MUST de-duplicate Inbox URLs and send to all unique Inbox URLs.
This has the nice property that when I'm consuming notices, I only need to read one of the many inboxes of a resource. But it has a bad failure mode. What if a sender didn't read this line carefully, or what if a sender crashed or lost network before sending all of the notices. Now some consumers will see it and others will not, unpredictably.
If you keep this MUST, I think you need to say, at least, that inboxes SHOULD all know about each other and perform a Byzantine consistency algorithm so they eventually become consistent. Otherwise these errors are just going to pile up and keep confusing everybody.
A better solution is to say either (1) there MUST be only one inbox (and if you want several, make that one be a service that makes sure each of the several desired inboxes gets the message eventually, or (2) say the sender can send to ANY of the inboxes, and the consumer MUST read all of them if it wants to get all of the notices.
(Also, if you do keep the MUST, then you need to spell out exactly what 'deduplications means'. Are "http://www.w3.org" and "http://www.w3.org/" the same thing? or "http://WWW.w3.org"? Details of how to do this are spelled out here: https://tools.ietf.org/html/rfc3986#page-38 . But just get rid of folks sending to all of them. )
[sent on behalf of Addison Phillips]
https://www.w3.org/TR/ldn/#discovery
Section 3.1 ("Discovery") contains an example of returning content type of text/html. This should include charset=UTF-8 by way of setting a good example.
Content-Type: text/html
<a href="/inbox/" rel="http://www.w3.org/ns/ldp#inbox">My inbox</a>
I think it's an unreasonably high burden to ask those people wanting to support linked data notifications to also support link header notifications.
The complexity of client side apps spiral when both headers and content must be stored, analyzed and acted upon.
I would suggest splitting the spec into two sections, or maybe two specs
And not closely couple them, but rather have modular units that can be taken on their own merits or both together.
Original implementations of LDN used/s the solid-terms namespace e.g., the inbox property which points to the Inbox URL. The spec considers to move this over to the ldp namespace. This issue is intended to have consensus on this proposal.
Considerations section should be informative.
Raised by @sandhawke
Raised by @dmitrizagidulin
Is everything that the Inbox URL references to is a notification (typically containing content in RDF)?
Considerations: Default LDP implementations may list everything in the container via ldp:contains. One case here is that, if that Container contains NonRDFSources, it'll be listed. This is probably not what we want. Then again, the Inbox container should probably watch out or filter non-RDF resources.
We might need to take this into account in how this is worded.
A resource MUST advertise only one Inbox
I presume this is primarily meant to mean that if the header is set site wide, the content MUST not contain an inbox discovery link.
Firstly, I think this violates web arch in that the document should not constrain the content. Let's say a site owner decides to set the inbox on a domain, now every time any document is edited, to be in compliance with the REC, the content must check that the header is not set.
Secondly, in RDF a resource can have multiple URIs for a given predicate. This can be partially mitigated with reasoning (functional properties). Ive had the case in the past of having a public inbox on databox, and a private one on localhost. So I can send timeline posts to two places. This is useful.
This could be fixed simply by removing the link header discovery section, or decoupling it from the main spec.
Related: #27
Test suite: https://github.com/csarven/ldn-tests
Suggested by @BernHyland :
Do we need to say anything about the receiver being responsible for generating a URI for a notification sent to the inbox? LDP says:
5.2.3.7 LDP servers creating a LDP-RS via POST MUST interpret the null relative URI for the subject of triples in the LDP-RS representation in the request entity body as identifying the entity in the request body. Commonly, that entity is the model for the "to be created" LDPR, so triples whose subject is the null relative URI result in triples in the created resource whose subject is the created resource.
5.2.3.8 LDP servers SHOULD assign the URI for the resource to be created using server application specific rules in the absence of a client hint.
5.2.3.9 LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose these application-specific constraints as described in section 4.2.1 General.
5.2.3.10 LDP servers MAY allow clients to suggest the URI for a resource created through POST, using the HTTP Slug header as defined in [RFC5023]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providing a desired string to be incorporated into the server's final choice of resource URI.
We could perhaps say this more succinctly.
Hi,
We've (Thales E-Security) done a brief and informal high-level security review of the current LDN draft (26 July 2016 version). Looks mostly OK with a few clarifications we thought would be useful.
Let me know if it helps
Thanks
Nick
TeS-W3CLinkedDataNotificationsHigh-LevelSecurityReview-271016-0849-122.pdf
i am sure that the LDP WG is aware of webmention, an #HTML5 protocol under development to satisfy a very similar set of use cases http://webconcepts.info/specs/W3C/TR/webmention. since both specs are under development by the same organization, it would be useful if LDN explained its relationship to webmention, and why it is inventing a new protocol.
Given the nature of the notification payload, consumers may want to take precautions when ascertaining the veracity of the contents. The open-world assumption applies here.
I am not sure how the open world assumption is relevant to the point there.
The bibliography links to "https://github.com/w3c/pubshubhubbub/" which is a misspelling.
The repo is now at https://github.com/w3c/pubsub and https://github.com/w3c/pubsubhubbub will redirect to it as well
[raised on behalf of Felix Sasaki and Addison Phillips]
The draft has a normative dependency on json-ld. One should have at least one example in the draft that shows the I18N aspects of json-ld, based e.g. on the json-ld string internationalization section https://www.w3.org/TR/json-ld/#string-internationalization
In fact we'd recommend adding language information to all examples containing natural language text, to convey the idea that it's useful information.
The example at https://www.w3.org/TR/ldn/#sending includes an @Type with an apparent English language value ("Announce"). There is no use of the JSON-LD @language context value to set the document language (in this case to English. Should there be?
This was originally a stub in the spec but removed when we started to work on it. Recently @BigBlueHat raised the following:
The examples show non identified (no id/@id) graphs hitting the inbox (which is fine), and the inbox assigning an id to it (which is also fine).
What is the expectation for these IRI's long term? Is the inbox expected to grow infinitely? Do they get moved off and renamed when "processed"?
I don't have a good answer for it yet...
Web Mention, Web Hooks, and http://www.relify.com/ (the LINK method returns!) all have these ephemeral things that disappear after transport (or at least are likely to). They effect things on the receiving end, but don't themselves have identification.
Email on the other hand has Message-ID and those (as we all know well) stick around long term and may or (sadly) may not be processed into better locations.
How do we go from here? Is this part of the spec? Non-normative?
Also, we only discuss POST in the spec, PUT can be added as well.
Proposal to use ldn resulting in URL: http://www.w3.org/TR/ldn
The term "inbox" has a very long history (long before there was a web) in the context of email. It carries very strong semantics, especially with regard to what mail delivery servers (MDAs in popular email terminology) and Mail User Agents (MUAs), including so-called split ones (e.g., POP3 and IMAP4 servers and clients) are allowed tor expected to do as well as a sometimes-precise relationship to a "mail store". This is especially important when internationalization is involved because those possible actions are expected to include language-selection or even automatic translation functions. While its primary use in recent years has been to allow plain-text and HTML-formatted versions of a message to be sent together, the multipart/alternative content type was introduced precisely to allow a mail message to be sent with versions in several different languages, with the preferred one selected by the user or her agent.
The relationship between an inbox and a mail store further complicates this LDN use because it is plausible to expect that, in some implementations, the same object storage mechanism might be used for email inboxes (or email message collections from while virtual inboxes can be constructed or views or on demand) and for LDN messages. One can also imagine the use of LDN to get "you have mail" or equivalent notifications to a user, further increasing to confusion between an LDN inbox and an email inbox.
The use of that term with rather different semantics and operations in the LDN context and the email context is an invitation for considerable implementer confusion and far greater user confusion when it leaks into user-level terminology and documentation. It, and this type of reuse of long-established and made-up, and therefore application-specific, terms more generally, should be avoided.
"depository", "container", "store" (perhaps with some prefix term) or some other term that does not have a specific and well-established meaning on the Internet would be more appropriate.
Section 3.4.2 states (emphasis mine):
"A successful GET request on the Inbox [...] MAY be subject to paging or access control restrictions at the receivers discretion"
If consumers may encounter paging, it may be helpful to mention the paging mechanism. Are we talking about LDP Paging? Something Hydra related?
Please clarify the difference between consumers and receivers.
In the context of receivers making an inbox accessible to consumers, the draft LDN specification states in section 3.4.2 that:
If the GET request has no Accept header, the results must be returned as JSON-LD; otherwise the receiver should return the results in the serialization requested, or a 415 Unsupported Media Type error if the requested serialization is not available.
I was planning to use an LDP server implementation as an LDN receiver, but the LDP specification (i.e. section 4.3.2.2) states that:
LDP servers should respond with a text/turtle representation of the requested LDP-RS whenever the Accept request header is absent
So in the case where the GET request has no Accept header, these two specs are pointing to different serializations. Would it be possible to get some clarification about that difference?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.