aboutsummaryrefslogtreecommitdiffstats
path: root/posts/group_communication_platform.md
blob: c81c1592f0fb77aa080a97cfeaffda4c51aee392 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
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?