this site is a folder of files, served from a content-addressed network under two names, with its source on radicle. each of those was a decision. this is the reasoning.
static
zola turns markdown and templates into html. zola build writes a folder, and that folder is the whole site. zola is a single binary and the only build tool. there is no package manager in the loop and no dependency tree we do not control. there is no database and no server-side code. nothing on our side takes input, so there is nothing to inject into and no login to phish. that is also why there are no forms and no comments. a page that only shows text does not need a login, and most pages that ask for one did not need it either. if you want to reach us, the email address is on the front page and the key to encrypt to is on /keys.
source
the source is on radicle. no third party sits between the repository and you. we only deploy from a commit, and the footer of every page names the commit it was built from. that means you can open the repository at that commit and read the source of the page you are looking at. a security company that will not show you its website source is telling you something.
check: rad clone rad:z3Dpw9mYPudazxq4wUQ1dviqpUAab, then git show the commit from the footer.
two javascript files
one flips the theme. the other is /sh, a few hundred lines so that every command on the front page runs. what you type there runs in your browser and never reaches us. there is no framework underneath either and nothing to npm install. a dependency is someone else’s release schedule, and we would have to watch it. two files is little enough that we can read all of it. there are also a few inline lines in the pages themselves. view-source shows all of them. every page except /sh reads with javascript off. the theme toggle needs it.
nothing is watched
no analytics, no cookies, no fonts or scripts from anyone else’s server. your theme choice and one flag for /sh live in your browser’s storage and never leave it. the machine that answers anonfunc.xyz has access logging off. you cannot check that from outside, so it is a promise. everything else in this section you can check with view-source. your resolver and the hosting provider see what they see. we do not need to know who reads this, and anything we collected we would have to protect. so we do not know if anyone reads this.
one address, two names
the site lives on ipfs. the address is a hash of the content, so if one byte changes, the address changes. anonfunc.eth points at it through a key we hold and a registration we renew. anonfunc.xyz points at it through a registrar. a registrar can take a name back. a key can be lost. the content is pinned on a node we run, and the machine that answers anonfunc.xyz serves the same build from disk.
check: dig +short TXT _dnslink.anonfunc.xyz and ipfs resolve /ipns/anonfunc.eth should agree.
keys
a scam usually starts with an email that looked right. every mail we send is signed with an openpgp key, one per address. the public keys are on /keys, and wkd serves them where mail clients that care about your security look. if yours does not, ask us which do, or read improve your opsec in 5 minutes. wkd only proves that the key came from this domain. compare the fingerprint with one you got another way. if a mail is unsigned, or signed with another key, it is not from us. that goes for every company you deal with. a mail that asks you for something and cannot be verified is a phish, whoever it says it is from. no other domain sends mail for us.
check: gpg --locate-key j@anonfunc.xyz, expect 1EBC CB83 FEAE 1501 8FC9 0DA2 D656 D280 EB37 9432.
if you disagree with any of this, or want to know more, write to hello@anonfunc.xyz. the key to check the reply with is on /keys.