aboutsummaryrefslogtreecommitdiffstats
path: root/posts/group_communication_platform.md
diff options
context:
space:
mode:
Diffstat (limited to 'posts/group_communication_platform.md')
-rw-r--r--posts/group_communication_platform.md142
1 files changed, 142 insertions, 0 deletions
diff --git a/posts/group_communication_platform.md b/posts/group_communication_platform.md
new file mode 100644
index 0000000..c81c159
--- /dev/null
+++ b/posts/group_communication_platform.md
@@ -0,0 +1,142 @@
+---
+title: Group Communication Platform
+published: 2015-08-11
+modified: 2015-08-12
+---
+
+**Update (2015-08-12)**: see
+[private-messaging-brainstorming](https://indiewebcamp.com/private-messaging-brainstorming)
+for a discussion on the topic of private messaging. It is in a way quite similar to
+the proposal below of "Inbox", but without OAuth.
+
+### Introduction
+
+This post will describe some typical features for a group communication
+platform with code name *Phubble*. As an example we will organize a
+birthday party for Alice. This post will describe what would be required of
+a "platform" to make it work for the IndieWeb.
+
+### Alice's birthday party
+
+Alice has a birthday in the near future. Bob, Eve and Mallory want to create a
+surprise party for Alice. Until now they used "Facebook Groups" to organize
+such an event among the friends.
+
+Bob wants to coordinate the party with Eve and Mallory and have a secure way
+of communicating among themselves without Alice, or anyone else finding out
+about it.
+
+The group of friends contains three members:
+
+- `https://bob.example/`
+- `https://eve.example/`
+- `https://mallory.example/`
+
+Bob creates a private space `alice-bday-party` on
+*Phubble* and assigns the members to it.
+
+*Phubble* will now have to figure out how to contact/notify the members
+by some mechanism to notify them they have been added to the private group.
+For example using an HTTP *inbox* or maybe email if an HTTP
+*inbox* is not listed on the member's homepage.
+
+Bob then posts his first idea to the wall. Eve and Mallory will receive a
+another notification saying that Bob posted a new message, possibly with the
+content of the message included, or maybe just a link.
+
+Eve wants to add Peggy to the group. She adds her to the group configured in
+*Phubble* with the identity `https://peggy.example/`. It
+should be possible for all members of a space to add new members. Only the
+creator can delete members.
+
+*Phubble* sends Peggy a notification that she was added to the
+`alice-bday-party` space, and will also inform her of any future
+activity.
+
+Peggy also has an idea and posts it to the space. Now Bob, Eve and Mallory will
+get a notification.
+
+### Notifications
+
+In order to notify a member (out of the blue) that he or she is a member of a
+(private) group space there needs to be a mechanism for doing this. Email has
+long been the most reliable way to do this. Most users will publish their
+email address on their homepage, for example using the
+[h-card](https://en.wikipedia.org/wiki/HCard) microformat as
+promoted for the IndieWeb or the
+[rel="me"](http://microformats.org/wiki/relme) method. In
+addition below a mechanism using HTTP is proposed, HTTP *inbox*.
+
+#### HTTP *inbox*
+
+The user advertises a HTTP *inbox* on their homepage:
+
+```
+ <link rel="inbox" href="https://tuxed.net/inbox">
+```
+
+This endpoint accepts a HTTP POST containing a subject and a message:
+
+```
+POST /inbox HTTP/1.1
+Host: tuxed.net
+Content-Type: application/x-www-form-urlencoded
+
+subject=New+message+in+%22Alice%27s+birthday%22+space&content=Lorem+ipsum+dolor+sit.
+```
+
+This request needs an OAuth 2.0 Bearer token to succeed. If non provided, the
+`inbox` endpoint will respond with some hints, as proposed by
+[OAuth 2.0 Authorization Server Discovery](as_discovery.html).
+
+```
+HTTP/1.1 401 Unauthorized
+WWW-Authenticate: Bearer
+ realm="Inbox",
+ authorization_endpoint="https://as.example.org/authorize",
+ token_endpoint="https://as.example.org/token"
+```
+
+Now *Phubble*, as an OAuth client, knows where to obtain authorization.
+*Phubble* chooses its own "authorization server", e.g. one that supports
+client certificates, and uses its own URL, e.g.
+`https://phubble.example/` as its identity. Assuming the AS supports
+[Distributed IndieAuth](https://indiewebcamp.com/distributed-indieauth)
+this should work perfectly well.
+
+Once the access token has been obtained it can be sent in the POST request:
+
+```
+POST /inbox HTTP/1.1
+Host: tuxed.net
+Authorization: Bearer SFmrZYeCR9hCol2ORAusJbccHiHrp7MU
+Content-Type: application/x-www-form-urlencoded
+
+subject=New+message+in+%22Alice%27s+birthday%22+space&content=Lorem+ipsum+dolor+sit.
+```
+
+Now the response will show it succeeded:
+
+```
+ HTTP/1.1 201 Created
+```
+
+#### Email
+
+Email is a safe fallback. The user's email address can be discovered from the
+homepage, for example by querying the `rel="me"` `link`
+headers:
+
+```
+ <link rel="me" href="mailto:fkooman@tuxed.net">
+```
+
+This will be all that is needed to send notifications.
+
+### Issues
+
+- How does *Phubble* keep track of new users in the ACL that need to be
+notified that they are now member of the space?
+- How do we deal with disabling notifications? Opt-in? Opt-out?
+- Should we implement a distinction between "invited" and "member"? So only
+when people accept a membership they will start receiving notifications?