Documentation/design_notes.txt

   1 Design notes and philosophy
   2 ---------------------------
   3
   4 public-inbox spawned around some basic ideas
   5 --------------------------------------------
   6
   7 * Public, non-real-time, archivable communication is essential to
   8   Free and Open Source software development.
   9
  10 * Contributing to Free and Open Source projects should not require the
  11   use of non-Free/non-Open Source services or software.
  12
  13 * Graphical user interfaces should not be required for text-based
  14   communication.
  15
  16 Challenges to running normal mailing lists
  17 ------------------------------------------
  18 1) spam
  19 2) bounce processing of invalid/bad email addresses
  20 3) processing subscribe/unsubscribe requests
  21
  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.
  26
  27 Use existing infrastructure
  28 ---------------------------
  29
  30 * public-inbox can coexist with existing mailing lists, any subscriber
  31   to the existing mailing list can begin delivering messages to
  32   public-inbox-mda(1)
  33
  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
  37   on public-inbox.
  38
  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
  41   is required.
  42
  43 * Atom is a reasonable feed format for casual readers and is supported
  44   by a variety of feed readers.
  45
  46 Why email?
  47 ----------
  48
  49 * Freedom from proprietary services, tools and APIs.  Communicating with
  50   developers and users of Free Software should not rely on proprietary
  51   tools or services.
  52
  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.
  57
  58 * All public discussion mediums are affected by spam and advertising.
  59   There exist several good Free Software anti-spam tools for email.
  60
  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 :)
  64
  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
  68   list.
  69
  70 * Email is already the de-facto form of communication in many Free Software
  71   communities.
  72
  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).
  76
  77 Why git?
  78 --------
  79
  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.
  84
  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.
  88
  89 Web notes
  90 ---------
  91
  92 * Getting users to install/run ssoma (or any new tool) is difficult.
  93   The web views must be easily read/cache/mirror-able.
  94
  95 * There may also be a significant number of webmail users without
  96   an MUA or feed reader; so a web view is necessary.
  97
  98 * Expose Message-ID in web views to encourage replies from drive-by
  99   contributors.
 100
 101 * Raw text endpoint allows users to write client-side JS endpoints
 102   without hosting the data themselves (or on a different server).
 103
 104 Copyright
 105 ---------
 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>