What happens when someone turns read-only items into read-write items by illegitimate means?
+ I subscribe to a collection (Apples) on Cosmo read-only
+ I compromise one of the items in that collection and re-share it in a different collection (Bananas), read-write.
- What happens?
- The item in question is stored twice on the server, in separate collections (Apples and Bananas), in separate user accounts. So the item that has been re-shared and is not connected on the server to the original item from the original read-only share.
- In my client, there will be a conflict when I sync the Apples collection. The version of the item from the Apples collection should always win.
What happens someone legitimately gains read-write privileges to an item that they previously had read-only access to?
+ Read-write access on the item overrides read-only access
Ways in which to gain read-write access to an item:
+ Subscribe to a share with a read-write ticket
+ Receive an item via email
Single-item URLs
+ Always share individual items from the user's All collection on the server
+ Users must have an account with the Hosted Service / a Cosmo server? in order to do item sharing
===
MERGING ITEMS
3 scenarios:
1. Losing touch. Connecting back up. Resultant conflict merge
+ A shares his contact with B. B stops sharing with A.
+ A shares his contact with C. B and C start sharing A's contact.
+ B and C have different versions of the contact.
What happens?
+ This is essentially a conflict merge and should be handled thusly. Most likely, C's version of the contact should win over B's.
+ Ideally, we have support for private annotations and any notes B jotted down could be stored as private annotations, rather than being overwritten.
2. Rationalizing items shared as 2ndary items with pre-existing versions of the same item
+ A shares an event with B. The To: field in the event points to a 2ndary contact item for C (e.g. To: C) which contains C's First Name and Last Name and C's email address.
+ B already has a contact item for C. We want to reconcile A's contact item for C and B's contact item for C.
+ However, A didn't intentionally share C's contact item with B. So A wouldn't want / expect B to make any edits to A's contact item for C.
+ This 2ndary contact item should be shared read-only
+ This 2ndary contact item needs to be rationalized / connected with B's contact item for C
Why can't we share C's email address just as a string? Why does it need to be an item at all?
+ Because, B is going to want to know all of the items that are related to C, regardless of whether those items point to B's contact for C; or somebody else's (e.g. A's) contact item for C.
+ We also want to be able to reconcile B's contact for C and A's contact for C at some later date, incase A and B decide to one day share a contact item for C.
QUESTIONS
+ Can we relate A's 2ndary contact item for C with B's original contact item for C, such that both are part of an uber-contact item that 'contains' or 'points back to' the 2 contact items for C?
+ Can we share secondary items as read-only, even if the primary item is shared read-write?
+ Can B 'annotate' A's 2ndary contact item for C (e.g. designate an email address from A's 2ndary contact item for C as the default email address to use when sending email to C)
3. Rationalizing import items with versions of the same items received via Sharing
+ A exports a collection and emails the collection to B
+ B imports the collection at which point, B can start to make changes to items in the collection
+ A then decides to share the collection with B
What happens?
+ When A exported the collection and emailed it to B, what was the motivation / expectation?
- Most likely, it was not: Keep my collection and B's version of the collection in sync
- More likely, it was: I'm making a copy of my collection for B, now B can do whatever they want with it
+ As a result, export, should really be: Export a copy
Q. Is this going to screw up scenarios where A is exporting items in order to back them up for himself? What if A loses part of his repository and then decides to re-import the back-up and ends up with a bunch of dupes?
+ Maybe we need both Export and Export copy; OR Backup and Export copy.
