1 Design notes and philosophy
2 ---------------------------
4 public-inbox spawned around some basic ideas
5 --------------------------------------------
7 * Public, non-real-time, archivable communication is essential to
8 Free and Open Source software development.
10 * Contributing to Free and Open Source projects should not require the
11 use of non-Free/non-Open Source services or software.
13 * Graphical user interfaces should not be required for text-based
16 Challenges to running normal mailing lists
17 ------------------------------------------
19 2) bounce processing of invalid/bad email addresses
20 3) processing subscribe/unsubscribe requests
22 Issues 2) and 3) are side-stepped entirely by moving reader
23 subscriptions to git repository synchronization and Atom feeds. There's
24 no chance of faked subscription requests and no need to deal with
25 confused users who cannot unsubscribe.
27 Use existing infrastructure
28 ---------------------------
30 * public-inbox can coexist with existing mailing lists, any subscriber
31 to the existing mailing list can begin delivering messages to
34 * public-inbox uses SMTP for posting. Posting a message to a public-inbox
35 instance is no different than sending a message to any _open_ mailing
36 list. Any existing spam filtering on an SMTP server is also effective
39 * readers may continue using use their choice of mail clients and
40 mailbox formats, only learning a few commands of the ssoma(1) tool
43 * Atom is a reasonable feed format for casual readers and is supported
44 by a variety of feed readers.
49 * Freedom from proprietary services, tools and APIs. Communicating with
50 developers and users of Free Software should not rely on proprietary
53 * Existing infrastrucuture, tools, and user familarity.
54 There is already a large variety of tools, clients, and email providers
55 available. There are also many resources for users to run their own
56 SMTP server on a domain they control.
58 * All public discussion mediums are affected by spam and advertising.
59 There exist several good Free Software anti-spam tools for email.
61 * Privacy is not an issue for public discussion. Public mailing list
62 archives are common and accepted by Free Software communities.
63 There is no need to ask the NSA for backups of your mail archives :)
65 * git, one of the most widely-used version control systems, includes many
66 tools for for email: git-format-patch(1), git-send-email(1), git-am(1).
67 Furthermore, the development of git itself is based on the git mailing
70 * Email is already the de-facto form of communication in many Free Software
73 * Fallback/transition to private email and other lists, in case the
74 public-inbox host becomes unavailable, users may still directly email
75 each other (or Cc: lists for related/dependent projects).
80 * git is distributed and robust while being both fast and
81 space-efficient with text data. NNTP was considered, but does not
82 support compression and places no guarantees on data/transport
83 integrity. However, an NNTP gateway (read-only?) is possible.
85 * As of 2014, git is widely used and known to nearly all Free Software
86 developers. For non-developers it is packaged for all major GNU/Linux
87 and *BSD distributions.
92 * Getting users to install/run ssoma (or any new tool) is difficult.
93 The web views must be easily read/cache/mirror-able.
95 * There may also be a significant number of webmail users without
96 an MUA or feed reader; so a web view is necessary.
98 * Expose Message-ID in web views to encourage replies from drive-by
101 * Raw text endpoint allows users to write client-side JS endpoints
102 without hosting the data themselves (or on a different server).
106 Copyright 2013, Eric Wong <normalperson@yhbt.net> and all contributors.
107 License: AGPLv3 or later <http://www.gnu.org/licenses/agpl-3.0.txt>