-Design notes
-------------
+public-inbox design notes
+-------------------------
Challenges to running normal mailing lists
------------------------------------------
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)
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.
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.
+ tools for for email, including: git-format-patch(1), git-send-email(1),
+ git-am(1), git-imap-send(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..
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
Why perl 5?
-----------
-
* Perl 5 is widely available on modern *nix systems with good a history
of backwards and forward compatibility.
Laziness
--------
-
* Stick to dependencies available in Debian main, this should make it
easier for potential users to install, and easier for distro
maintainers to pick up.
Web notes
---------
-
* Getting users to install/run ssoma (or any new tool) is difficult.
The web views must be easily read/cache/mirror-able.
* Raw text endpoint allows users to write client-side JS endpoints
without hosting the data themselves (or on a different server).
+What sucks about public-inbox
+-----------------------------
+* Lack of push notification. On the other hand, feeds seem popular.
+
+* some (mostly GUI) mail clients cannot set In-Reply-To headers
+ properly without the original message.
+
Scalability notes
-----------------
-
Even with shallow clone, storing the history of large/busy mailing lists
may place much burden on subscribers and servers. However, having a
single (or few) refs representing the entire history of a list is good