dokieli is a clientside editor for decentralised article publishing, annotations and social interactions https://dokie.li/
I can see dokieli UI saying sometihng like: this inbox prefers to have all of the resources mentioned in the notification to be public-read, do you want to make it so (annotation public-read) and then send a notification"?
if user says nopes, then it can proceed with the annotation but won't sent a notification.
server or some inbox agent or whatever.. needs to keep an eye on what's coming in any way.
That's only for the initial entry. Of course the annotation can be private at any time. So, I suppose seomthing like an inbox agent can do its management at its leisure.
@bencomp Do you mean that their UI lets you know that some annotations are marked as private and that you can't actually read the annotation?
We could do that now.. but I don't see the point. Unless we add stuff like 'Ask Alice if you can read this resource'
@csarven I believe a long time ago I saw somewhere on their website Hypothesis say they support Web Annotations, but I haven't discovered yet how. The UI indeed lets me select access levels for each of my annotations. Other users won't even know that I created a private annotation. It would be nice if dokieli also allowed me to adjust access permissions, so that I don't need to either think of setting them on the container beforehand or realising afterwards.
@bencomp I've documented the architecture of Hypothes.is at: https://csarven.ca/linked-research-decentralised-web#hypothes.is , and an overview of interop alongside dokieli: https://csarven.ca/linked-research-decentralised-web#dokieli-hypothes.is
@bencomp Setting access permissions is a non-issue. Planned todo. I agree, nice to have.
What I was saying earlier about H's case was that, because the client application works with a preconfigured H server, it already knows which annotations to show or not for the user.
@dmitrizagidulin Not sure what your takeaway was, but practically there is not much to go with. They're doing their own thing.. different identifiers for humans and machines, hardcoded URI templates, each client instance is wired up to only speak with a particular server.. Sounds awfully familiar? no WAP, LDP, AP.. So, dokieli can't talk to their stuff. There is one area of interop (IIRC have mentioned): if annotations that dokieli created somehow gets migrated to H's server, their client could potentially reuse it.. but since they have all data coming from elsewhere and their client is mostly depended on it, who knows what'd happen. dokieli can't reuse their stuff because it can't discover it.. and there is no way in hell dokieli will hardcode an arbitrary URI Template =)
If so, yes. Recent W3C spec's HTML and dokieli's is quite similar, so it was straightforward. The CSS worked mostly out of the box.
See also https://linkedresearch.org/ldn/ for the ED. That has a few other things like inbox/annotationService.. and loads dokieli - showcases LDN as well.
I only used ReSpec so far but not super convinced by it
There is also Bikeshed
I will remove the checkbox for localStorage because that's clutter. It autosaves to localStorage but there is no way to recall. Basically what needs to happen is if dokieli detects that you were in offline mode and have changes that's "ahead" (just document modified timestamp for now probably) it will prompt the user about that situation and ask them if they want to update the HTTP resource
I suppose that will happen automatically right now any way.
So, maybe we just need to remove the checkbox for localStorage. Hmm.
^ @timbl Re AutoSave
Need to track the hash of last save's content.. and only save if different hash
I realise the convenience and less clutter of not showing the autosave checkbox (although many software do).
GoogleDocs doesn't have it IIRC
PUT text/html
dokieli uses OPTIONS heavily for notifications and annotations.
Any opinions on whether autosave to localStorage at 1m interval should always be on? And also remove the checkbox option to enable/disable that?