Egregoros · Phoenix Framework

witch_t *navi

@navi@social.vlhl.dev

wannabe hacker just going around

a c witch using gentoo, openrc dev, and wine/vkd3d hacker

♫♪ a thing of beauty, i know, will never fade away ♪♫

<3 @lizzy@social.vlhl.dev

Posts

Followers

Following

Posts

Latest notes

witch_t *navi

@navi@social.vlhl.dev remote

if i use srv records, to say, point _imaps._tcp.vlhl.dev to 993 on ivy.vlhl.dev

the tls certificate for the imap server in that port, does it have to be for vlhl.dev or for ivy.vlhl.dev?

witch_t *navi

@navi@social.vlhl.dev remote

@leo my plan was to only have servers at subdomains, e.g. $hostname.vlhl.dev -- and not have anything directly on vlhl.dev, but have srv records pointing to the actual services i run

i wanted to do this for pendantism and a clean network topology, not a technical reason

but i guess that doesn't quite work, and, can i even ask for a cert that goes ivy.vlhl.dev and vlhl.dev if those end up going on different machines for some reason? aka, how does the acme challenge work in that case

witch_t *navi

@navi@social.vlhl.dev remote

@leo i never did a dns challenge before so i have no idea how it works :V

every time i just did it over http-1, so i shall research dns acme challenges

witch_t *navi

@navi@social.vlhl.dev remote

@leo okay namecheap makes that painful

though i suppose i could move my dns in my own servers, dunno if they let me do that but would be cool

witch_t *navi

@navi@social.vlhl.dev remote

@leo i am surprised to "the nameserver has to be a domain name", since i'm used to things like 1.1.1.1 and 8.8.8.8 giving me the idea that nameservers are addressed by ip, like if they were A or AAAA records in the top level domain

so, interesting

witch_t *navi

@navi@social.vlhl.dev remote

so proton mail does use pgp? no keyserver tho

then why in hell do they not let people use smtp and imap directly, why force the bridge down onto everyone?

plenty of other clients have supported pgp for ages

RE: https://social.vlhl.dev/objects/54294066-32ea-4bf4-ab65-9cf9fac3ad83

witch_t *navi

@navi@social.vlhl.dev remote

@atax1a they don't need to get it into smtp proper, not at first at least -- esmtp supports extension discovery via EHLO, so give the server a PROTON_E2EE extension and if supported, use e2ee by some standard extension protonmail would document themselves

now any MTA can implement that, make use of it -- eventually if google doesn't budge, we still have plenty of other options

witch_t *navi

@navi@social.vlhl.dev remote

@atax1a then i do not understand your point about google controlling SMTP development, we can do our own thing, but protonmail does not want to

witch_t *navi

@navi@social.vlhl.dev remote

@atax1a sending email to google was never part of the problem i described

the problem i described is protonmail selling itself on e2ee while having it's backend software proprietary, and having no intention of improving the wider ecosystem, basically funneling people to use protonmail so they can have encrypted conversations with other protonmail users, and *only* other protonmail users

never mentioned google, and they have nothing to do with the problem at hand

witch_t *navi

@navi@social.vlhl.dev remote

@toiletpaper

> PGP/GPG

yes because non-techies famously don't have issues setting it up

pgp encrypted email has a huge ui/ux issue and makes it so you can't just send someone an email and have it just work™ -- that's the promise protonmail gives

> If it's not implemented by the MUA, then it's not really e2ee. MTA's already have TLS, DKIM, etc.

ofc MUAs need to support it too, but the whole stack needs to be aware so we don't end up delivering unreadable emails and confusing people even more

if pgp encrypted emails were enough, protonmail wouldn't exist

witch_t *navi

@navi@social.vlhl.dev remote

if proton mail were serious about improving e2ee email, they would've worked to have a standard extension for e2ee via smtp that other MTAs could implement, so that encrypted emails would not be limited to proton mail's non distributed, non self-hostable, proprietary smtp servers

witch_t *navi

@navi@social.vlhl.dev remote

how bad is it to create a new fedi account with the same username in the same instance as a previously created-then-deleted account?

asking because fedi is fucked up and prone to blowing up

witch_t *navi

@navi@social.vlhl.dev remote

@rose i'm not a fan of jq's complex dsl -- i use it when i have to, but honestly i like the concept of something like https://github.com/tomnomnom/gron a lot better

though i didn't try to use gron on my workflow yet