From jman to ~sircmpwn/sr.ht-discuss
> I have a quick question about DKIM validation in your mailing list software. The message at > https://lists.sr.ht/~sirodoht/mataroa-community/%3Co7uwxdbkfoyrelu5qgudcaetsg54kjeiywdecsqnwk5e6zkqjf%402kw32aoe7zt4%3E > is said to have an invalid DKIM signature I'm not 100% sure of how it works, but Wikipedia says the verification is done by searching this TXT DNS record dkim._domainkey.startmail.com Which I don't seem to find in your config. Could this be the reason? I used to this other tool to verify my DKIM: https://mxtoolbox.com/dkim.aspx
From jman to ~sircmpwn/sr.ht-discuss
I would like to open a discussion thread about the current status and future of Sourcehut. I'd be happy if this email could stimulate a discussion with project maintainers and other Sourcehut users. As an outsider of the project, I can get a feel about the progress of Sourcehut by reading the blog. Last post (March 2023) is about the financials of the previous year: https://sourcehut.org/blog/2023-03-27-2022-financial-report/ Latest technical progress report, October 2022: https://sourcehut.org/blog/2022-10-18-whats-cooking-october-2022/ ### Places where conversations happen The mailing lists sr.ht-dev and sr.ht-discuss are the places where public conversations happen, so
From jman to ~sircmpwn/public-inbox
Thanks for sharing your thoughts. > The new situation forces all others to share their their source code under > AGPL, but allows them to sell closed-source proprietary forks. In other words, > it's a "everyone else must share code under AGPL except us" situation. In that blog post they also mention they if they wanted, they could have made a closed-source fork at anytime: > (EDIT: to be clear, the sole reason for a CLA is to allow Element to > dual-license the software (...) not to give Element the ability to > relicense to a non-OSI license in future. After all, Element already > had that ability with the Apache license, and has not used it.)
From jman to ~sircmpwn/public-inbox
Hey, I am reading about the fork of the Matrix servers (Synapse and Dendrite) operated by Element: https://matrix.org/blog/2023/11/10/this-week-in-matrix-2023-11-10/#synapse-website The current projects are owned by the Matrix Foundation and licensed as Apache-2.0. The new fork by Element will use the AGPLv3 license and will require contributors to sign the Apache CLA: https://www.apache.org/licenses/contributor-agreements.html#clas
From jman to ~sircmpwn/sr.ht-discuss
Hi Drew, I've noticed this commit: https://git.sr.ht/~sircmpwn/sr.ht-nginx/commit/e6d3721 and then I read this comment on Github[0] ("[...] I have blacklisted Mastodon User-Agents across SourceHut's services."). I'd like a bit more context. What does it block exactly? Is this blocking just images being fetched for previews? Which Sourcehut services does this affect? Example: what happens if a Mastodon instance tries to fetch a link in a Sourcehut mailing list? Does it affect also pages.sr.ht?
From jman to ~toastal/github-less-social
Signed-off-by: jman <srht@city17.xyz> --- aggressive.txt | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/aggressive.txt b/aggressive.txt index 3577163..af2e748 100644 --- a/aggressive.txt +++ b/aggressive.txt @@ -22,3 +22,8 @@ github.com##.dashboard-changelog:upward(aside,div) github.com##.Header a:is([href^="/codespaces"], [href^="/explore"], [href^="/marketplace"]) github.com##.ActionListItem:has(a:is([href^="/codespaces"], [href^="/explore"])) github.com##.diffbar-item:has(a[href^="/codespaces"]) [message trimmed]
From jman to ~toastal/github-less-social
Hey, thanks for this useful project! I also maintain a personal blacklist of GitHub UI elements I find distracting. My pet peeves are avatars, so I just replace them with a black placeholder. It may be even be a little bit extreme :) but I can't go back to seeing those distracting PNGs while doing my work. The patch also has a link to the uBlock Origin relevant documentation for other options. Submitting this patch for evaluation, but feel free to ignore it. Thanks! jman (1):
From jman to ~sircmpwn/sr.ht-discuss
> A proposal: we should implement organizations, which are an entity > representing a group of users which can collectively own resources like > git repositories. I'm curious if this discussion led to some document establishing the way forward to have organizations in Sourcehut. A roadmap would also be great. Drew, any update/deliverable out of this discussion? Thanks
From jman to ~sircmpwn/sr.ht-discuss
>> FWIW, I know people have trouble sending me email from *.xyz addresses >> because apparently these domains are too often abused by spammers, so >> messages from such domain carry a heavy "stigma". > > Thank you for the information. I was not aware of this when I chose the > domain. This is unfortunate. As owner of an .xyz domain I feel compelled to interject when the argument is raised that .xyz domains are used by spammers. This is NOT the case ANYMORE. Please check the statistics from Spamhaus[0] or any other similar spam report entity.
From jman to ~sircmpwn/sr.ht-discuss
>> You can write a script to do that and then commit the boilerplate >> files. > > So, I urge the user to run that script through my README? See what would work best for you. One idea could be having a repository with a sample script, invite users to clone your repository, configure this script and then run it to configure their own repository on Sourcehut. Something like this (not tested): ----------s---------s---------- #!/bin/bash