csarvenIn dokieli-annotation.webm the user has the option to store their annotation (which ends up being the canonical copy) into their personal storage. When oa:annotationService is detected, it has the option to send a copy to that container as well. A notification is sent to the article's inbox (using an as:Announce snippet) with references to the canonical location. When the article is loaded, dokieli looks into article's inbox to find all applicable
csarvenOther possibly interesting bits here are: WebID, personal storage space, an annotation service, an inbox.. and they can all be potentially at different domains. In the screencast, WebID and the personal storage space are on different domains, inbox and annotationService are on the same domain but running different software.
csarvenOne of the first issues I've hit was when each domain with an annotation required authentication. The beautiful cert pop-up per domain. That was annoying. But, that was resolved on the server end (in Solid in this case).
csarvenLDN notifications can be anything so they can be reference or a copy. The way I use them is by reference but I can see that they can just contain the complete data. In ActivityPub for instance, LDN Inbox gets a copy from an AP (same as in its Outbox)
csarvenI think what we need to explore more of is ldp:constrainedBy and SHACL, and having applications capable of detecting the constaint models and preparing their payloads as such. And servers validating the incoming payload so that they can better filter and organise the notifications.
csarvenI dislike dialing numbers to connect to people - I have to either dig up a webpage for the codes or hunt down an email about it. Next to that is finding someone's email address to message them. Why is life so difficult?
cwebber2sandro: let's skip the administrivia. the one thing I'm seeing... we're delaying the CR transition votes on LDN and AP a week for a variety of reasons mentioned in the agenda. Anything anyone has to say about those?
cwebber2rhiaro: we're basically waiting for review from a few people who said they would, we got the i18n review, they're going to confirm they're happy with the changes, and we have one security issue with is 43. we think we don't need to do anything but need to run it by the group
cwebber2rhiaro: yes, and the person said "if this is acceptable then that's fine, you should just mention it in the security considerations section". I don't know if we need to say it twice
sandrotantek: Can you capture the feedback & issues raised elsewhere in github, so we can see how ti's processed and handled, and to give us evidence of wide review for W3C process
cwebber2tantek: at the face to face we stated that we'd be trying to keep pushing CR specs to PR and I want to keep asking those questions of those CR specs if we have editors for them
cwebber2aaronpk: webmention, did a couple of updates to the report indicating more clearly the test coverage results... otherwise, not much changed, and on micropub I've been continuing to work on adding tests and collecting implementation reports now. Hoping by next week to have all that wrapped up.
cwebber2tantek: that would be good to capture... especially the CSRF implementation, is that something everyone doing a web form to webmentions has to support?
cwebber2tantek: definitely not strictly required. from the webmention test results, maybe push the MAY to the bottom of the list or something, to clearly indicate those are tests for MAY in the spec
cwebber2... especially since it's for looking at how to do things external from the working group, which is exactly where we're likely to see requests from. if there can be some good instructions... it could be informative, as long as the mechanism works
cwebber2tantek: if there's an extensibility point in micropub for mp-instructions by the endpoint instead of content of the post, they're specified in micropub as mp-syndicate2, there's a comment about how people can add more
cwebber2tantek: I think if you can point to a process on how to do things for the mp-* extensions, could be good to say here's a lightweight process on how to formalize/make official
ben_thatmustbemeI sort of wish W3C had a process of noting "references" in the bottom of specs automatically, thus any future Notes / Specs would be listed automatically. This could inclcude community group published docs which then becomes a location for public extensions that is actually still under w3c control
cwebber2tantek: yes we need to see how much time we have to be in CR... I think we talked about htis at the f2f and we had changes pending, looks like aaronpk made those changes
cwebber2sandro: it's pretyt important for the community... it's not normative for current implementations, but is normative for extensions. ah yes, here's why it's normative. If I make an extension foo, and then I see foo, is it my foo vs someone else's? we don't know unless we all agree we're participating in the same registry of extensions
tantekPROPOSAL: Publish an updated CR of Micropub with the normative change in response to i18n issue raised during first CR, and editorial changes too.
tantekPROPOSAL: Publish an updated CR of Micropub with the normative change in response to i18n issue raised during first CR, and resolving issue 62, and editorial changes too.
tantekRESOLVED: Publish an updated CR of Micropub with the normative change in response to i18n issue raised during first CR, and resolving issue 62, and editorial changes too.
tantekif there's any chance of getting our second Micropub CR out by Thursday (transition emails done by tomorrow sometime?) that would be great. 4 weeks is a long time to wait again to go to PR.
tantekrhiaro - additional request (which will likely impact every other document we have) - can you find when out when is that latest that we can schedule both CR and/or PR transition requests? E.g. in December *before* the publication moratorium?
tantekFYI: those of you working on CR->PR for your specs, you should also consider documenting how you will accept, process, and document errata once your spec is a REC. E.g. "github issues, processed in SWICG, documented ... github wiki or w3c wiki or another page on your one-off .net domain etc."