about summary refs log tree commit homepage
path: root/Documentation/design_notes.txt
blob: a5c0bba846a22a6a9db7c702858a7bbe334dd467 (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
Design notes and philosophy
---------------------------

public-inbox spawned around some basic ideas
--------------------------------------------

* Public, non-real-time, archivable communication is essential to
  Free and Open Source software development.

* Contributing to Free and Open Source projects should not require the
  use of non-Free/non-Open Source services or software.

* Graphical user interfaces should not be required for text-based
  communication.

Challenges to running normal mailing lists
------------------------------------------
1) spam
2) bounce processing of invalid/bad email addresses
3) processing subscribe/unsubscribe requests

Issues 2) and 3) are side-stepped entirely by moving reader
subscriptions to git repository synchronization and Atom feeds.  There's
no chance of faked subscription requests and no need to deal with
confused users who cannot unsubscribe.

Use existing infrastructure
---------------------------

* public-inbox can coexist with existing mailing lists, any subscriber
  to the existing mailing list can begin delivering messages to
  public-inbox-mda(1)

* public-inbox uses SMTP for posting.  Posting a message to a public-inbox
  instance is no different than sending a message to any open mailing
  list.

* readers may continue using use their choice of mail clients and
  mailbox formats, only learning a few commands of the ssoma(1) tool
  is required.

* Atom is a reasonable feed format for casual readers and is supported
  by a variety of feed readers.

Why email?
----------

* Freedom from proprietary services, tools and APIs.  Communicating with
  developers and users of Free Software should not rely on proprietary
  tools or services.

* Existing infrastrucuture, tools, and user familarity.
  There is already a large variety of tools, clients, and email providers
  available.  There are also many resources for users to run their own
  SMTP server on a domain they control.

* All public discussion mediums are affected by spam and advertising.
  There exist several good Free Software anti-spam tools for email.

* Privacy is not an issue for public discussion.  Public mailing list
  archives are common and accepted by Free Software communities.
  There is no need to ask the NSA for backups of your mail archives :)

* git, one of the most widely-used version control systems, includes many
  tools for for email: git-format-patch(1), git-send-email(1), git-am(1).
  Furthermore, the development of git itself is based on the git mailing
  list.

* Email is already the de-facto form of communication in many Free Software
  communities.

* Fallback/transition to private email and other lists, in case the
  public-inbox host becomes unavailable, users may still directly email
  each other (or Cc: lists for related/dependent projects).

Notes
-----

* Expose Message-Id in HTML views to encourage replies from drive-by
  contributors

Copyright
---------
Copyright 2013, Eric Wong <normalperson@yhbt.net> and all contributors.
License: AGPLv3 or later <http://www.gnu.org/licenses/agpl-3.0.txt>