Date | Commit message (Collapse) |
|
It would be too much of a burden for caching system when
user-supplied CSS is more powerful.
|
|
Followup-to: 1365e185d817cdc2de04968c37f597d92226a13b
("view: inline message reply into message view")
|
|
A public-inbox is NOT necessarily a mailing list, but it
could serve as an input point for zero, one, or infinite
mailing lists :D
|
|
Quote-folding was a major design mistake pre-1.0. Since this
project is still in its infancy and unlikely to be in wide
use at the moment, redirect the /f/ endpoints back to the
plain message.
|
|
Start documenting our anchors and CSS classes for in case users
want to write their own CSS or even JavaScript for local usage.
|
|
Quote-folding can be detrimental as it fails to hide the
real problem of over-quoting.
Over-quoting wastes bandwidth and space for all readers, not
just WWW readers of the public-inbox. So hopefully removing
quote-folding support from the WWW interface can shame those
repliers into quoting only relevant portions of what they reply
to.
|
|
Setting the "In-Reply-To:" header via mailto: links is not
well-supported and should probably not be encouraged unless
the client situation improves.
So instead, teach users more widely-supported ways of setting
the In-Reply-To: header to ensure proper threading of replies.
|
|
This requires POST and (small file) upload support from the
PSGI/Plack web server. CGI.pm is currently not supported with
this feature.
We'll serve everything git can handle by default for performance
in the general case.
To avoid introducing cognitive overhead for sysadmins managing
existing HTTP backends, we do not introduce new configuration
directives.
Thus, setting http.uploadpack=false in the relevant git config
file for each public-inbox (ssoma) git repo will disable smart
HTTP for CPU/memory-constrained systems.
Technically we could support http.receivepack to allow posting
messages to a public-inbox over HTTP(S), but that breaks
the public-inbox model of encouraging users to Cc: everyone.
Again, we encourage users to Cc: everyone to reduce the chance
of a public-inbox becoming a centralized point of
failure/censorship.
|
|
Add a few newlines for readability (perhaps at the expense of
economy). Stop mentioning "Open Source" as it is redundant
and "Free Software" fits our goals, better.
|
|
Despite best intentions, things like strike-throughs and italics
won't render well and will harm accessibility.
|
|
This allows common /m/ links to be used without a prefix,
saving 2 precious bytes for permalinks and raw messages.
Old URLs continue to redirect.
|
|
The MIME type entry for Atom feed relies on "atom",
so allow properly-configured static file servers to serve
it with the correct Content-Type header.
|
|
This allows users to subscribe to only a single thread
with their feed reader without subscribing to the rest of
the thread.
Update our endpoint notes while we're at it.
|
|
This improves compatibility and allows individual messages
to be concatenated into an existing mbox without further
modifications. "git format-patch" does something similar
(but does not do "From " line escaping(!))
|
|
Threading in Xapian is mostly supported by now; so start
documenting things.
|
|
Table rendering in lynx is crap compared to w3m and links.
However, we still use it for filtering HTML since the renderer
is otherwise nice...
|
|
SpamAssassin queries URI blacklists, so it's probably OK
to start generating links in the future...
|
|
Hopefully this simplifies and corrects our usage of Perl encoding
APIs.
|
|
While we're at it, make sure strange characters are escaped properly
in Message-IDs. We'll need tests for all this behavior.
|
|
This is not a blog. All posts, whether replies or not,
carry equal weight.
|
|
Document some of the stranger choices I've made.
|
|
We have an HTML homepage, OMG!
|
|
This allows WWW readers to slowly page through the entire history
of the mailing list.
|
|
We'll probably support these so they're easier-to-type and share.
|
|
Remove the specified /all.html while we're at it, we only have
/all.atom.xml because it's convenient for feed readers.
|
|
Message-IDs are extremely long already, so try to keep them short here.
|
|
We serve the short, abridge-quote version by default since
it is (unfortunately) common practice to over-quote on mailing lists.
|
|
Mainly, start with URL routes since that's what users usually
see, first.
|