the more i think about it, the more i conclude that @sir is right and git forges aren’t the right answer.

which is really a shame because i hate email
Show thread
but sourcehut has a very compelling workflow
Show thread
what i like about sourcehut is that it just connects tools together. i think this is an example of @sir at his most brilliant.

you can have an email workflow, or not.

you can have web-based reviews, or not.

what is most compelling is that, with functional ActivityPub groups, we could have a workflow where we discuss the changes right here, in the fediverse, and reach consensus on it, and then it makes it into the repo. all of this is possible because of the sourcehut plumbing.
Show thread


I really want to like sourcehut, and these are excellent points in its favour.


One of my biggest concerns is that policy is hardcoded in to the software. e.g. the flat refusal to accept multipart emails merely because one part is HTML makes it impossible to discuss HTML attachments, and it actively impedes simple support inquiries via email (e.g. a users ML) which may result in a potential user looking at another project.

(Speaking as someone who’s been using the internet and writing emails almost as soon as they were able to read… the anti-HTML email crusade was lost decades ago.)

@Aerdan i'm sure those issues will be resolved in due course, now that alpine is breathing down his neck.


Had an argument on fedi a few weeks ago about it, he wouldn’t even accept any mechanisms for downgrading the HTML. There was also a patch offered to just quietly drop the HTML attachment, which was also rejected.

So, it’ll have to be some pressure indeed to make him change it.


seems the problem with removing the HTML attachments is that it breaks the DKIM signature, which does have consequences.


I don’t know that there’s a solution to ‘no HTML email’ if “does not break DKIM signatures” is more important, then.

I do know that there should be an option to permit HTML email on a per-list basis, however.


that seems like a reasonable compromise. @sir what do you think?

@kaniini @Aerdan I really, really, really, really do not want HTML email on HTML is a pox on email and my goal is its elimintation from the internet. 99 out of 100 MUA vulnerabilities are email-related, for obvious reasons. It has no place in an MUA and I'm not going to let you burden subscribers of my lists with this awful mail format.

@kaniini @Aerdan a stated goal of is to improve the ecosystem, and getting bad clients which only support HTML emails to play ball is part of that

@sir @kaniini @Aerdan For *users* (not developers) who want to use a mailing list for help (e.g. alpine-users), it's unacceptable to bounce HTML email unconditionally. Not all clients support plaintext-only, and I really doubt that your project is going to change that. What leverage do you have over Apple, Microsoft, and Google? And, before you counter with "just use a different client", that is not an acceptable response either, *especially* in the case of lists designed for helping end users

@sroracle @kaniini @Aerdan I expect those clients to change. Most clients *do* support plaintext email, those which do not are in the minority and will be corrected.

@sroracle @kaniini @Aerdan frankly if that's a dealbreaker for you then sourcehut is not the platform for your needs.


@sir @kaniini @Aerdan okay, then perhaps the alpine-users email list should be moved to a more reasonable platform.

@sroracle @kaniini @Aerdan I'm talking about the policy of upstream. For the alpine lists I'm going to fight hard against plaintext but at the end of the day it's not my call alone

Sign in to participate in the conversation
Interlinked MST3K

this is mst3k