X-Git-Url: http://www.git.stargrave.org/?a=blobdiff_plain;f=Documentation%2Fdesign_notes.txt;h=3df5af3e3cf204c7954830d22a0de8b7fbd1d5e1;hb=174588f860f4ecda1896559928b6c72bf2857832;hp=d96c8d8247cbdf4654ebb8157d89492522ffbe65;hpb=f76f265a851944b5dedcc3be5f3b5224b6ebda89;p=public-inbox.git diff --git a/Documentation/design_notes.txt b/Documentation/design_notes.txt index d96c8d82..3df5af3e 100644 --- a/Documentation/design_notes.txt +++ b/Documentation/design_notes.txt @@ -3,6 +3,7 @@ public-inbox design notes Challenges to running normal mailing lists ------------------------------------------ + 1) spam 2) bounce processing of invalid/bad email addresses 3) processing subscribe/unsubscribe requests @@ -14,9 +15,10 @@ 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-mda(1) or public-inbox-watch(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 @@ -25,20 +27,19 @@ Use existing infrastructure * 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. +* Readers may continue using use their choice of NNTP and mail clients. * 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. +* Existing infrastructure, tools, and user familiarity. 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. @@ -53,7 +54,10 @@ Why email? * git, one of the most widely-used version control systems, includes many 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. + is based on the git mailing list: https://public-inbox.org/git/ + (or + http://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/git/ + for Tor users) * Email is already the de-facto form of communication in many Free Software communities.. @@ -64,25 +68,34 @@ Why email? 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. + integrity. However, read-only IMAP and NNTP gateways are implemented. -* As of 2014, git is widely used and known to nearly all Free Software +* As of 2016, 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. + and *BSD distributions. NNTP is not as widely-used nowadays, and + most IMAP clients do not have good support for read-only mailboxes. Why perl 5? ----------- + * Perl 5 is widely available on modern *nix systems with good a history of backwards and forward compatibility. * git and SpamAssassin both use it, so it should be one less thing for admins to install and waste disk space with. +* Distributing compiled binaries has higher costs for storage/cache + space is required for each architecture. Having a runnable, + source-only distribution means any user already has access to all + of our source. + 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. @@ -106,11 +119,11 @@ Laziness * 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 built-in git protocol support! Web notes --------- -* Getting users to install/run ssoma (or any new tool) is difficult. + +* Getting users to install/run 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 @@ -119,30 +132,27 @@ Web notes * Expose Message-ID in web views to encourage replies from drive-by contributors. -* Raw text endpoint allows users to write client-side JS endpoints +* Raw text endpoint allows users to write client-side 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. +* marketing - as it should: + 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 -for small lists since it's easier to lookup a message by Message-ID, so -we want to avoid splitting refs with independent histories. -ssoma will likely grow its own builtin ref rotation system based on -message count (not rotating at fixed time intervals). This would -split the histories and require O(n) lookup time based on Message-ID, -where `n' is the number of history splits. +See the public-inbox-v2-format(5) manpage for all the scalability +problems solved. Copyright --------- -Copyright 2013-2015 all contributors -License: AGPLv3 or later + +Copyright all contributors +License: AGPL-3.0+