Mailing lists are resistant to censorship
sourcehut.org
sourcehut.org
Let's work backwards from this desired command line:
youtube-dl -U
We have 2 main areas to implement:
1) the code artifacts: a source code repo (and binary releases for download) ; for Linux kernel, I think this is "www.kernel.org"[1]
2) the workflow: the issues / bug reports / pull requests ; for Linux kernel collaboration, a popular mailing list is "majordomo@vger.kernel.org"[2]
If youtube-dl switches from github to mailing lists, how would the "-U" command work? Would somebody need to setup a SMTP server (or at minimum, a SMTP email account) dedicated to youtube-dl? Would youtube-dl then use SMTP protocol to scan the mailing list for which server has the latest code artifacts?
Does making youtube-dl act as a pseudo email-client make it RIAA proof? Are SMTP servers beyond the legal reach of RIAA?
EDIT to reply: This article is about the developer workflow, not about what the end-user software should do.
I understand that but I think it's productive to go beyond that and think out loud what a realistic implementation could be to help end users. Besides, many end users are also the code contributors.
If they can continue to share patches over distributed mediums like a mailing list, they can continue to collaborate, and share improvements to the youtube-dl code that many already have copies of.
Possibly not a fantastic long-term solution, but certainly worth attempting whilst fighting it out with the RIAA.
Another important point is that many projects use GitHub as their general communication about issues, support, roadmap, etc. When GitHub suspends a repo, all of it goes away. Whereas Sourcehut is selling the point that your collaboration tools would survive even if they were required to remove your code.
At minimum, a mailing list allows you to coordinate shifts to a new repository location, which might be hard if all of your communication was via GitHub.
So, in any case, it looks like the idea is not good to fight that issue (right now no one prevents anyone from sending his copy of the master of youtube-dl and letting other people reproduce it/develop it). The use of a mailing list is just an improvement over this but it should be perfectly possible (for the RIAA) to take it down as well.
youtube-dl -U
Fetching signed update from usenet over TLS...
Validating GPG signiture...
Installing...
Updated to youtube-dl-20201029
* use the blockchain to distribute a magnet link for the latest revision, and
* use the torrent protocol to download the latest revision
"We’ve updated our language to further clarify our Rules (Section 17 of STOU), which state that Mailchimp does not allow the distribution of Content that is, in our sole discretion, materially false, inaccurate, or misleading in a way that could deceive or confuse others about important events, topics, or circumstances."
I'm going to look into moving to one of the many of the cheaper, more trustworthy competitors if what you have commented is true.
You can continue an existing thread with known individuals without the mailing list, true. And that undeniably has value, and can be used to re-form connections after loss of the mailing list, and that's great. It both adds value to ongoing use of emails and adds value beyond its lifespan (compared to not ever existing).
But the list is how many people contribute. The list is how general discussions occur. The list is how new contributors join and contribute, as they lack other connections. Without the list, which can be censored just like github, a massive connection-increasing piece of the community is still gone. I feel pretty confident arguing that that is the feature that separates git from github, and email from mailing lists, and it's no more resistant to censorship than any other centralized system.
If you can get the git repo, you don't need the list to contribute. It helps, for sure, but you can work without it pretty easily.
And as I said in the article, I don't think it would be necessary to turn off the list in the event of a DMCA request, at least not on SourceHut. On GitHub the git repo is the single source of truth, so when a git repo is pulled, so too go the issues, pull requests, and so on. Not so on SourceHut.
Open issues and similar will likely also get lost unless restores, unless you count "exists in someone's inbox/archive" as "the issues and pull requests continue to exist". Because in my opinion, that's barely better than having no backup as all relational data in regards to these things is lost.
"No it doesn't" isn't a valid DMCA defense.
They don’t, but that they don’t isn’t because your GitHub repo is “baked into one thing”, it’s because they’ve chosen to apply the DMCA at the repo level rather than playing whack a mole with your content.
Using a mailing list archive instead of an issue list doesn’t change that dynamic. What changes it is that you’ve decided to use more targeted DMCA compliance for SourceHut, which is noteworthy. But the delta here is a policy delta, not a technological limitation on GitHub’s part.
Sure, they could do that, but - have they? No. SourceHut has.
GitHub has gotten a ton of (justified!) criticism because the issues/PRs are not stored in git (either in the main repo, like gh-pages branches, or in an associated repo, like GitHub repo wikis).
The “changes” they’d need to make beyond their current DMCA implementation would be to restrict the “Code” tab, the Readme preview, and the git/ssh endpoint for that repo. Which would likely be a new feature, but given they already have the ability for a repo’s owner to totally disable PRs or issues, certainly wouldn’t be the kind of groundbreaking change you’re pitching it as.
2) Now you'll be playing a game of whack-a-mole with content. The DMCA will likely indicate all infringing content is to be taken down with some examples, so you can start taking down content there but unless you exactly know what content in the repo is infringing, you're likely going to be at the other end of a lawsuit in short order if you don't delete the whole repo.
Right, but the repo and the other features are fundamentally not the same thing on SourceHut. It's entirely unnecessary to take down the mailing list (perhaps to take down the archives, but not stop accepting future emails) to comply with a DMCA notice. The mailing list and the repository are not joined at the hip like they are on GitHub. And the service provider is not obliged to be creative in finding the broadest possible scope of infringement: the onus is on the DMCA author to provide a list of infringing material.
Also; the DMCA can simply request you take down the entire repository. You will have to comply with that until further notice, that is how this functions. You're not allowed to investigate or look into the matter a-priori.
The problem that I see with society in general is that many of us have a strange attachment to these services (GMail, Facebook, Github, Youtube, Evernote, whatever) to the extent of outright dependency and diminished wherewithal to try something different, even if it may be to our advantage in the long run.
I sympathize with people, such as Mr. DeVault to an extent, who are determined to invite people to alternatives that are not entirely foreign. In the case of his well documented campaign to re-emphasize mailing lists with git, it appears to be a return to its original format. It is also worth mentioning his efforts in educating people how to use this traditional method.
If a person has no intention of ever publishing something that threatens the status quos and bylaws of Big Colorful Corporations and and their pals within governments and elsewhere, then what difference does it make?
Be it on a git server, a website, or a major publication, whatever it may be, as society begins to slither towards regression and oppression on various fronts, the most skilled people, will be those of the most sound moral character and belief who have the acumen to navigate a world that is actively plotting against them.
These sort of efforts are not necessarily irrelevant to a greater cause, when put in the proper perspective.
Another consideration is Fossil. Fossil artifacts are identified by a SHA1 hash or SHA3-256 hash, so you can make a magnet URI involving it. SHA1 hashes are listed in the Wikipedia article for magnet URIs; SHA3-256 isn't, although it would still be possible to do (perhaps "urn:sha3-256"). Fossil also includes a HTTP server (or can run on an existing HTTP(S) server), which the artifacts can be downloaded from. Some Fossil artifacts are structural artifacts; if it is a manifest of a check-in then its data will list the name and hash of each file. (I do not know how Git and Mercurial work; I do not know about how the similar things would work with Git/Mercurial, if any.)
You do not really need to build that into an NNTP server; you can just have something like rss2email for NNTP running locally. There is a way to do it with CNews though: https://tldp.org/HOWTO/Usenet-News-HOWTO/x714.html
Mailman can forward list messages to newsgroups, which is something you do want to do on the listserv server side: https://docs.mailman3.org/projects/mailman/en/latest/src/mai...
Also check out DFeed: https://github.com/CyberShadow/DFeed
A lot of activism in my city happens on facebook, and it's simply terrible.
Perhaps emails are a bit more difficult to use, but it is important skill to master, especially in context where you have to self organize and discuss. It's also very democratic, because opening an email account is faster.
And in terms of "real" privacy, emails are better, just because they are decentralized.
https://www.youtube.com/watch?v=I_O3zj3p52A (technical talk starts around 22:30)
It isn't quite decentralised but fairly resilient. The more mature local chapters can replicate much of this if need be and in any case the use of technology is quite fluid.
This is not the situation youtube-dl will find itself in now.
They have also been known to collaborate with cops, which as a protestor is the exact /last/ thing you should be doing -- since the state's motivation is simply to put down all protests regardless of their method of protesting. You can see this in the UK with the laws against even peaceful protests. And have shown a blatant disregard for taking advice by more experienced protest organizations, some of which have been around for almost a century.
All of that being said, I don't think it's very possible to compare youtube-dl, which is a bundle of source and the surrounding contributors, to an on-the-ground protest movement. While there are similarities, there are also many disparities.
For what it's worth, youtube-dl is in a much easier position. Their main website is still operating, and all they have to do is prod people that they know to silently take over, and have those people make an announcement. IANAL but someone that they trust but who is not primarily involved would be ideal. They don't have to hand over the keys to the website, just allow those people to make public notifications stating they are the primary replacement, and have them continue the project -- under perhaps a different name and branding. Like ffmpeg and avconv.
Those first two paragraphs strongly depend on the location, in particular the situation wrt. police. Many countries (certainly mine, the Netherlands) do respect the right to protest and employ the police to facilitate and protect these rather than to 'put down all protests'.
When activists seek the limits of these protections, e.g. with blockades, I think it's right that they seek to find the way to be most effective, which can involve negotiating with authorities or choosing not to pick certian battles. Case in point, Amsterdam has employed 'bestuurlijke verplaatsing' (stuffing people in to buses rather than arresting), which is legally iffy but it's a) less work for authorities and b) much better than getting properly arrested. A status quo that allows more inclusive mass actions.
Real people don't need stuff to work perfectly, because they'll come up with a workaround by moving platforms or changing how they do things. Nothing works perfectly for them anyways. The platforms they use just need to work 95% of the time, and be good enough. Real people are aware that what they write can be read by others, and don't care about the difference between whether it's encrypted in transit, or on the server, or to their recipient.
For real use, it's all about the content, not the platform.
I guess most people don't use it yet. The problem with Gitlab is also that it doesn't federate. All the project metadata stays on Gitlab. One can import from Github, but then you're stuck on Gitlab.
Maybe tools like fossil[0] or git-bug[1] will pick up steam, but I have a feeling the current events will simply pass and next week we'll be talking about something different. In the meantime, some people will switch or consider alternatives and everytime this happens again, the number of those people will grow. Progress is slow.
[0] http://it7otdanqu7ktntxzm427cba6i53w6wlanlh23v5i3siqmos47pzh...
Does anyone know of a good guide to mailing lists?
And also for configuring your client for plaintext, which is strongly preferred by most mailing lists:
If you or anyone else reading this is ever anxious about making mistakes in their early posts on a mailing list, feel free to send the email you'd like to write to me first - sir@cmpwn.com - and I'll look it over and make any suggestions if necessary.
What I don't understand is how the mailing list itself works. When I want to start a thread, I send an email to the list. When I want to reply to someone, do I email the list or the person? How do I make sure the emails are threaded properly? During my first mailing list interaction I ended up emailing another developer directly somehow.
The git email client seems to have support for message IDs. They seem to work just like post identifiers in forums. Mail clients like mutt let users actually edit the email's headers and include metadata like that. I'm not sure if gmail does it behind the scenes.
Also, gmail has moved on to newer authentication mechanisms. Is there a simple plain text email client with native support for this? Mutt apparently requires an external program which is seemingly unmaintained.
Most people will (and you should, too) use reply-all when participating on a mailing list, which should land the replies straight into your inbox. Just reply-all to these normally, making sure not to top post. If someone makes a mistake, and you weren't subscribed to the list, the web archives usually have a mailto: link somewhere that you can click to reply to the thread.
>The git email client seems to have support for message IDs.
You should never have to directly work with message IDs if you're using git-send-email and letting your mail client handle replies.
>Also, gmail has moved on to newer authentication mechanisms.
They should still have support for SMTP PLAIN authentication unless you use gsuite and your admin has turned it off, if I understand correctly. I have written a mail client which has support for OAUTH, however, which you might find useful:
I don't use gmail so if you run into problems, please reach out to the appropriate mailing list - I won't know how to help.
I would also, of course, strongly recommend that you ditch gmail ASAP.
In certain cases, if you want to include a patch in an email reply to an existing patch series (using the scissors delimiter), you would need to use git format-patch and send-email using the in-reply-to option so that the reply ends up in the correct place.
That said, I haven't seen this particular feature used in the years I've followed the git mailing list, so perhaps it's not commonly used.
Reply to person, CC the list.
> How do I make sure the emails are threaded properly?
Using In-Reply-To header that references parent Message-ID. Git asks for it when sending a patch.
Which mailing lists recommend against using the In-Reply-To header referencing the previous cover letter?
Using the In-Reply-To header requires foreknowledge of email headers, the purpose of Message-ID, and how to find it. It's not very approachable. Most mailing lists who have thought about it don't ask users to do it.
Is this sarcasm? Because I know folks that consider anything but plain text emails to be rude.
This is what I do at work. My work uses Outlook which does not support format=flowed [2], meaning my plaintext emails would look weird to colleagues who use the standard Outlook settings. Outlook will also default to responding in plaintext to a plaintext email. To avoid forcing my preferences on my colleagues, I now use an automatic filter [3] to convert my plaintext emails into HTML using a Markdown parser. My email client then sends both parts: the HTML and plaintext part as a multipart/alternative email.
[1]: http://www.mutt.org/doc/manual/#send-hook
[2]: https://joeclark.org/ffaq.html
[3]: http://www.mutt.org/doc/manual/#send-multipart-alternative-f...
Next question.... overriding reply-on-top for mailing list replies? :)
>Theoretical responding author:
>Yes, but there is a good reason for that.
There is an example linked [0] in the first blog post and I honestly don't understand how to read it. A lot of information is being drowned out by the patch file. The diff is in a separate tab on Github. The response hierarchy is inverted.
>Theoretical responding author:
>You'll get used to it in no time.
The idea of responses being a quote inside the text they are responding to is absurd. I honestly can't comprehend it. Usually people quote the text they are responding to, not the opposite. Why do things have to be so complicated? Github doesn't even have a hierarchy. It's just an ordered list of messages.
However, there is another reason why no one should use gmail for anything serious. There is always a risk that you may get shut out of your account without recourse, taking down access to other services along with it.
- what happens after you send the email?
- Is there somewhere I can pull that up on sourcehub?
- Does feedback come to the email attached to my git user?
- if the maintainer decides to apply my patch, does it still show up as my patch, or theirs?
- Yes, there are online archives available for each mailing list.
- Yes.
- Both. It shows up with you as the author and them as the committer.
Twitter censors direct messages, why can’t Gmail censor who can email whom?
I run a data driven self help website and there is no paywall or advertising on the website. Everyone clearly signs up for emails. I still get above 0.5% spam+bounce ratio which means I need to ask Amazon for forgiveness everytime I email. (4x per year)
Yes I purge the lists, don't use clickbait, etc...
If 0.5% can get you into spam folders, this is an easy attack vector to silence someone.
My bigger question is how Walmart, Joann Fabrics, and HBO get into my mailbox. I'm sure they get "marked as spam" by more than 0.5%
Meanwhile I'm grepping through mailing list server logs and going "your provider accepted it without error, don't know why it's not hitting your inbox."
I would have never known if I hadn,t looked through my Spam on Gmail.
I didn,t get the job, but I got a nice aep to San Jose and back.
It was from a yahoo-inc.com address, probably not used for spam much.
Since then, never trusted it... I comb through all my spam every couple of days. Takes only couple of minutes to skim it 20 at a time.
Would recommend, technique has paid off.
Legacy e-mail should be gone for good, with its 7-bit headers (it takes 24 bits to represent a 8-bit symbol in "quoted-printable"), codepage hell (most of the Americans can hardly understand, meanwhile e-mail software still doesn't default to UTF-8), overquoting tradition (most of the people quote all the messages of the thread below every message and the software encourages this), pointless subject field encouraged for every message (which usually remains intact when the subject changes, and often is of little informativeness from the very start), incompatible HTML formatting, etc.
Aren't you reinventing email exept its compatibility to every device on the world? Compatibility and availability are sometimes more usefull than the tax of legacy systems.
No, in fact I'm just dreaming about the return of FidoNet, which already had none of these problems back in the 1990-ies ;-) Sure, there was no UTF-8 yet, but a standardized set of 8-bit ASCII codepages was already not bad though - you could always tell the codepage given the language/country and you didn't have to fit a symbol into 7 bits.
And this is an illustration of FidoNet-style concise quoting: quote just an atomic idea, answer it, then quote the next one:
> ...
This way.
Whoever needs to see the whole original message you are answering - it's up there in the thread tree, just a button away. And it is meant to be automatically pre-downloaded for you.
Meanwhile, almost every single e-mail message I get just includes the whole thread quoted under its actual body (duplication level = insane). And it looks and works very weird when people actually need to respond to particular parts of my message paragraph-by-paragraph.