search

linkeddata / dokieli

:bulb: dokieli is a clientside editor for decentralised article publishing, annotations and social interactions
https://dokie.li/
Other
788 stars 81 forks source link

Add option to mark annotation as private #115

Open csarven opened 8 years ago

csarven commented 8 years ago

The annotation UI should offer an option to mark the annotation as private in the user's storage. So, this will set the ACL.

Depends on https://github.com/linkeddata/dokieli/issues/93

csarven commented 8 years ago

This might need some additional machinery to have it working. If the annotation is marked as private, then the target of the annotation's inbox shouldn't get a notification - we presume that private is "private" i.e., no one gets to know it was created or even exists.

This might also mean that we need to be careful about how this is 1) called by the user when they are looking at the target - we presume that this issue is not only for saving an annotation, but also being able to fetch it back, and 2) viewed by the user in context of target.

Would 1 mean that a special container is kept in user storage which is checked? Would 2 mean that for privacy reasons (in case the application is doing something it shouldn't do), the annotation shouldn't be put back into the DOM where the target is at?

rhiaro commented 8 years ago

the target of the annotation's inbox shouldn't get a notification

Yes

being able to fetch it back, and 2) viewed by the user in context of target

Right now we don't have a Settings dialogue where the user would tell dokieli where they want to save their annotations (related #77, #149); the way I see it working is once we do have its it can just fetch annotations with the appropriate target from here at the same time it fetches from the document inbox. (It would need to dedup public ones by the current user which would appear in both places).

for privacy reasons (in case the application is doing something it shouldn't do), the annotation shouldn't be put back into the DOM where the target is at?

I don't really understand the privacy problem here. dokieli is 'the application' and we know we're not doing anything weird. The user using dokieli has chosen to trust some things it does, so they should probably just trust everything. Putting in the DOM for that particular user for that particular session, so long as it is never going to save into the document should be fine. The problem is if the document owner modifies dokieli to do malicious things once a document viewer has authenticated. But this problem is a general one, not specific to the private annotations. Technically someone could modify their instance of dokieli (or any other solid app) to steal all of someone's data once they've authenticated, so.. I think fixing that might be out of scope for dokieli's issues.

csarven commented 8 years ago

we know we're not doing anything weird

That's the best case scenario, but dokieli is not currently aware of the other things that's going on in the same document session, and I think it has room to take some responsibility of its own actions. Perhaps one responsible thing for dokieli to do would be to confirm with the user: "You are about to display your personal/private notes here, ... Continue/Cancel?" or arguably better, let the UI hint at it early on, e.g., [] Display personal notes.

There is a balanced UX somewhere that's good to aim, so that the user is aware of what's going on, without scaring or interrupting them.

rhiaro commented 8 years ago

not currently aware of the other things that's going on in the same document session

Right, that falls under someone having the possibility to modify dokieli, in which case they could also modify it to remove any warnings :p If anything, 'you are about to display your personal/private notes here' is confusing... for me I'd be like "why are you warning me about this? are you going to share it with someone? what's going on? do you know something I don't?" I'm sure there's some way we can make this nice, but I think an 'are you sure?' when the user doesn't have any information to make a decision about why they would or wouldn't want to do this seems like bad/disruptive UX.

e.g., [] Display personal notes.

I think I already made an issue for turning annotations on/off in general, so we could augment that with on/off for public and private annotations separately.