Group: GNU Social P2P/Use Cases
Contents
Overview
This set of use cases set the initial direction for this effort. The use cases are marked with releases (R1, R2, etc.). R1 is the initial beta release. R2 is a production release while R3 is a mass market release.
Users
Jane is a power user.
John is a generic user.
David is a casual user.
Cory is a potential user.
Mallory is a malicious third party.
Glossary
App - an instance of a GNU Social / Daisychain application owned by a specific end-user
Applet - a plugin to an App providing additional functionality. Applets may be trusted or untrusted to various levels, using a granular permission model. [1]
Friend - a person connected to the end-user (can be an acquaintance or co-worker)
Server - a machine or VM that is not used as a desktop
Provisioning
Self Hosted
Destkop - David installs the Daisychain application on his desktop computer. A wizard opens allowing him to perform initial configuration. R2
Hardware - John acquires a low-cost server. John plugs power and network connections, then uses a browser to specify a location to install from. After installation completes, the initial configuration page is shown. R3
Third Party Hosted
Rented - Jane rents a virtual machine from an ISP, paying with a credit card. She specifies a Daisychain VM image to be loaded on the VM. After installation is complete, she uses a browser to perform initial configuration. R2
Turnkey - David signs up for a free account from Daisychain company X. [2]R1
Configuration
Initial - Turnkey
David enters the following configuration information: name, nickname, password. David is then redirected to his personal URL - https://nickname.companyx.com/ . The SSL certificate was automatically generated. R1
Initial - Desktop/Hardware/Rented
John enters the following configuration information: name, nickname, password, dyndns provider, SSL certificate provider (or self-signed). The application automatically provisions the domain name and certificate with the help of the providers' API. If the server is behind a firewall, it automatically negotiates an open port with the router using UPNP. R2
Initial Friends
By name - John enters Jane's name. Because John is not yet connected to anybody, a set of search engines are queried to locate Jane. John may fail to locate Jane if she did not opt-in to a search engine. R2
By URL - Jane enters John's URL. John sees a friend request from Jane and accepts. Jane confirms that the cryptographic fingerprint matches using a side channel (e.g. phone). She adjusts John's permissions. R1
Adoption and Friending
Friend of Friend
By Name - David enters the name of a new acquaintance Jane that he met through John. Because David is already connected to John, David's app does not need to contact global search engines - it just searches John. R2
Browsing - David browses John's visible friends and notices that he knows one of them. He sends a friend request to that person. R1
By URL - Jane enters David's URL that she got from his business card. R1
Public Profile
Cory sees Jane's Daisychain url in the signature of an email she sent him. He clicks on the URL and is presented with her public profile. A link "Get Daisychain" encourages him to get his own profile. When he clicks on the link, he is directed to a set of choices for acquiring a turnkey profile. A "more choices" link leads him to additional choices categorized under Desktop, Hardware, Rented, or Turnkey. R1
Daily Usage
Media
Jane opens her private profile page and reads notifications from her friends. She notices new photos uploaded by John. She clicks on the album and is presented with a view of John's photos. R1
Jane comments on a photo. The comment is attached to the photo in John's app and is visible to other friends. [3]R2
Messaging
John sends a message to Jane. The message is entered in the messaging applet in John's app. Jane receives notification as a popup on her application pages. [4]R1
John sends a message to David. David receives notification on his XMPP client from his app. R2
Instant Messaging
John sends an instant message using his app's web interface. David receives the message through his XMPP client. The message appears to have originated from John even though John is not currently using XMPP. R2
Posts
John creates a blog post in his app. Notification of the post is sent to all of his friends that are permitted to see his blog. R1
Search
John is looking for a post but can't remember which of his friends posted it. He performs a search, which expands to include his friends. David's app returns a hit. When John clicks on the hit, he is presented with the post. R2
Applets
Install of Untrusted Applet
David is looking through John's blog posts, and decides that he would like to blog too. He clicks on the "Add This Applet" button, which redirects him back to his own app and presents him with a permission page. The permission page tells him that the applet will have permission to communicate with his friends' instance of the same applet, and nothing else. David accepts. (NOTE: applet output needs to be sanitized, e.g. with Caja and applet needs to be firewalled in order to conform to this permission set) R3
Install of a Trusted Applet
Jane wants to install a new messaging app. The messaging app permission page requests permission to present unsanitized HTML and to have access to other applets' data. The applet code is signed by a trusted friend of friend. She accepts. R3
Permissions
Setup
Jane defines a "co-worker" friend tag. She assigns this tag the following permissions: view content tagged with "work", view friends tagged with "co-worker". R1
The "acquaintance" friend tag is set by default to be able to see friends tagged with "acquaintance", "friend" and "spouse". R1
Jane defines a "special friend" tag. She assigns this tag the following permission: view content tagged with "public" and "special". No other friend tag is able to view this one. R1
The "private" tag is configured by default to make content invisible to everybody other than Jane. R1
Search
David searches his friends' blog posts. Jane has some posts tagged with "special". These posts are not returned by Jane's app when the query is processed. R2
Sharing
Jane shares a post tagged with "private" with David. The post is then visible to David even though it is tagged with "private". R1
Security
Encryption
John is viewing David's photos. Mallory is not able to view the photos in transit. R1
Authentication
Mallory can see John's public profile, but he is not able to see anything else on his app instance. R1
Backup and Restore from Friends
Jane backs up to David and John. She saves a public key that can prove her identity to her friends' apps and can decrypt the backup. R2
Jane's hosted instance is on a machine that experiences a hard-disk failure. She creates a new instance, enters David's and John's URLs. She then restores the data from David and John. Because the backup was continuous, she did not lose any data. R2
Restore from Third Party Storage
John's configures his hardware instance to back up to a third party storage service. A key is randomly generated and John prints it and places it in a safe place. R3
John's hardware instance fails. He buys new hardware and points it to the third party for a restore. He types in a long hex key as well as his usual password to decrypt the backup. R3
Footnotes
- ↑ See the Android platform permission system
- ↑ Turnkey provisioning is for the case where the user does not want to manage their own box or VM for various reasons, such as cost or maintenance.
- ↑ John can delete Jane's comment. This capability is not always desirable - it may be better if Jane could host the comment and make it available to other friends out of John's control.
- ↑ An issue arises if Jane navigates away from her app - she will not be notified until she returns. If friend generated content is pulled and displayed inline, this is less of a problem.
