-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.
+Design notes
+------------
Challenges to running normal mailing lists
------------------------------------------
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
+ instance is no different than sending a message to any _open_ mailing
list.
+* Existing spam filtering on an SMTP server is also effective on
+ public-inbox.
+
* 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.
list.
* Email is already the de-facto form of communication in many Free Software
- communities.
+ 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
------
+Why git?
+--------
+
+* git is distributed and robust while being both fast and
+ space-efficient with text data. NNTP was considered, but does not
+ support delta-compression and places no guarantees on data/transport
+ integrity. However, an NNTP gateway (read-only?) is possible.
+
+* As of 2014, git is widely used and known to nearly all Free Software
+ developers. For non-developers it is packaged for all major GNU/Linux
+ and *BSD distributions. NNTP is not as widely-used nowadays.
+
+Laziness
+--------
+
+* A list server being turned into an SMTP spam relay and being
+ blacklisted while an admin is asleep is scary.
+ Sidestep that entirely by having clients pull.
+
+* Eric has a great Maildir+inotify-based Bayes training setup
+ going back many years. Document, integrate and publicize it for
+ public-inbox usage, encouraging other admins to use it (it works
+ as long as admins read their public-inbox).
+
+* Custom, difficult-for-Bayes requires custom anti-spam rules.
+ We may steal rules from the Debian listmasters:
+ svn://anonscm.debian.org/pkg-listmaster
+
+* Full archives are easily distributable with git, so somebody else
+ can take over the list if we give up. Anybody may also run an SMTP
+ notifier/delivery service based on the archives.
+
+* Avoids bikeshedding about web UI decisions, GUI-lovers can write their
+ own GUI-friendly interfaces (HTML or native) based on public archives.
+ Maybe one day integrated MUAs will feature a built-in git protocol support!
+
+Web notes
+---------
+
+* Getting users to install/run ssoma (or any new tool) is difficult.
+ The web views must be easily read/cache/mirror-able.
+
+* There may also be a significant number of webmail users without
+ an MUA or feed reader; so a web view is necessary.
+
+* Expose Message-ID in web views to encourage replies from drive-by
+ contributors.
-* Expose Message-ID in HTML views to encourage replies from drive-by
- contributors
+* Raw text endpoint allows users to write client-side JS endpoints
+ without hosting the data themselves (or on a different server).
Copyright
---------