How to use this site
What is dynode?
Literally? One of a series of electrodes intended for use as
electron multipliers.
Technically? A repository of markup files, images and other data
cached on various hosting services, with a slick domain pointed
towards it.
Etymologically? A portmanteau of the words ‘Dyna’ and ‘node’,
stylised for aesthetic purposes.
Spiritually? A collection of my ideas and musings, documenting the
work of the DSC and the transition away from the dependency on
withering hierarchies - that for now, has taken a form which is
accessible online through any standard Web browser.
Where is dynode?
dynode is everywhere, and not particularly anywhere. The entire site is an IPFS data object, and so any peer on the main DHT may help to host the object. There may be thousands of those peers, or even more.
Why is dynode?
dynode as it exists today serves multiple functions, but its earliest was as a general proof of concept for an easily-manageable and cheap solution to the extant problem of self-reliant global information distribution. Though generally a blog for distributed technologies (and general experiments in digital self-publishing), I might also veer onto the subject of politics, among others, to the extent that they relate.
When is dynode?
dynode is currently preceding the inevitable downfall of the capital-W ‘Web’, eagerly anticipating its imminent replacement with an information distribution paradigm that outclasses the efficiency, security, and freedom of the existing system. It may be considered a frontline in the ongoing anti-Web effort.
How is dynode?
This one will take a little longer.
The pages of dynode are written in the Markdown implementation of
Pandoc, with articles, and image
files separated by directory (/a and /i and respectively). When the files for the site -
which also includes my PGP key - are ready to
be made public, they are signed with my public key and the directory
is added to IPFS with the simple ipfs add -r dynode
command (where the -r flag denotes adding recursive
directories).
The CID of the resulting IPFS object (the directory) is then loaded through the official ipfs.io gateway, and that of Cloudflare, to make sure it gets cached by both, and thus is widely and quickly accessible. The object shall also be mirrored in a Git repository to keep a clearer track of changes, although observing the history of the site via the changes in IPFS CIDs which I sign and archive is also possible.
It is simply a matter then of updating the DNS records via
Namecheap. Initially I had pointed the domain to my regular peer ID,
which was to point to the object on my machine (the
/dynode directory) and periodically update as my IPNS
record does. Since resolution speeds for this were far too low, I
moved to caching the files on free hosting services and popular HTTP
gateways instead (also giving the benefit of their
infrastructure). This also allowed me to not need to maintain a node
which regularly re-publishes IPNS records, as by default they have a
finite expiry time of 24 hours.
The TXT records of a dig query to the domain offer a
clearer look as to how dynode works:
The first value is the verification for my Keybase account, through which
I also verified
my Twitter account. The second provides verification for my IRC vHost
on Rizon.
The third is the SPF
record detailing emails to any @dynode.io address
are to be redirected to my main address. Finally, the fourth is the
DNSLink value
pointing to the IPFS object that contains dynode’s files. Not listed
here are redirect records, chiefly, a masked frame to dynode’s files
via Cloudflare’s gateway (which would’ve changed, not for their censorship
practices, but because handing them even more of the world’s
traffic is surely unwise - alas, all the alternatives suck).
Together, they allow dynode to be accessed in multiple different ways, through multiple different domains:
dynode.io
dynode-io.ipns.dweb.link
dynode.io.ipns.localhost:8080
Accessing dynode.io through a standard HTTP browser
will take one to the frame delivered via gateway. Since this method
is essentially just a <frame> tag, there is no
dedicated server of which to speak, so there is no transport security
that may be offered via this means (ie, the address is always
http://). There are a couple more limitations here, in
that linking directly to pages in this way
(e.g. http://dynode.io/links.html) is not possible, and
that the address does not change when navigating through the
site.
The latter 2 URLs use DNSLink to pull the object via IPNS, though ultimately it still loads the same object.
dynode-io.ipns.dweb.link is a public gateway, and the
preferable option for most by which to load the site. Running IPFS is
not required on the user end to visit it, and one may link directly
to pages using this method
(e.g. https://dynode-io.ipns.dweb.link/links.html#OSINT),
as well as see which page is currently loaded. As gateways will tend
to cache the objects that are loaded through them for some time, this
may also tend to be quicker than using a local node (unless that
local node also has the object cached). The dweb.link
service, run by Protocol Labs, is just one example of a public
gateway which may be used, but most any of them can be -
e.g. dynode-io.ipns.ipfs-gateway.cloud or
dynode-io.ipns.c4rex.co.
dynode.io.ipns.localhost:8080 is the typical address
for local gateway access. It generally offers the same benefits as
public gateways, but the connections are made via a local IPFS node.
If the other addresses are visited in a browser with IPFS
Companion while a local node is running, they will redirect to
this one.
Both DNSLink methods allow transport security within a Web browser, and will default to it if you use a browser or gateway that forces it - and having managed to have serendipitously pulled some strings in that department, there should be no shortage of HSTS-enabled gateways ready to load dynode in minimal time.
As the subdomain of a public gateway request might still be visible via Server Name Identification request in the TLS handshake, and thus, the entries the DNS records point to, it is likely that this transport security gives little real benefit anyway, especially considering that for now, only static content is being loaded.
There are 2 ways of avoiding this worry. One is the use of
gateways which point to objects via path rather than subdomain
(e.g. https://ipfs.io/ipns/dynode.io), as DNS requests
will simply show the gateway domain. The other is the use of Encrypted
SNI to obscure
the subdomain which contains the object, or better still, the
improved TLS extension Encrypted
Client Hello; however, present support for these (which you can
personally check for in the case of the latter via the DEfO website) is disappointing
to say the least.
If you wish to avoid ISP or other 3rd party DNS snooping without using a VPN regardless, then accessing the site through non-WWW means (i.e. a local node or its gateway) may provide the best guarantee here. The introduction of DNS in the chain actually creates a convenience / security trade-off here that would not ordinarily be a matter in regular DHT (IPNS) resolutions, as there is no worry there in waiting for each element of the network to update to a new set of best practices. Of course, all of this just bolsters the case for the adoption of better naming systems (as the DNSLink team suggests), such as the GNU Name System.
Is dynode a ‘Web’ site?
Depends on how you look at it.
Given that dynode is accessible through a Web browser using
standard protocols of the Web stack, it would indeed be fair to
consider it to be a site on the Web. Really, this
consideration is multi-dimensional; one may load dynode without
having to touch Google Chrome or any other browser. It is possible
for example, to simply use command line utilities like
wget to grab pages from the site (ie the patrician
way), and view them locally. But the other dimension, the option
to avoid HTTP entirely, is also available.
Running your own IPFS node (an IPFS daemon process) offers a way
to explore dynode without having to use any WWW infrastructure.
Running ipfs pin add /ipns/dynode.io allows one to
download, cache and seed the object locally. From there it can be
accessed in a browser via localhost, or the HTML files can simply be
outputted to terminal via cat or other tools. Through
the use of IPLD, a deep-dive can
also be taken into dynode’s hash tree structure itself, and changes
to the object can be tracked much more closely.
There are a number of security benefits all of this provides which outshines a regular WWW / HTTP setup. Should a DNS provider ever see fit to end my service, one could simply link to the object address the DNS record pointed to, with zero loss of content uptime. Because of how IPLD verifies the Merkle DAG structure of objects, dynode in its present form is perhaps the closest one may get to an ‘open source’ site accessible on the Web, in that the complete set of content on the site can be inferred simply through the base CID, itself signed by my PGP key - an advantage I apparently did not require a TLS certificate to achieve.
Due also to how IPLD forces content to be verified before returning it, and the nature of the content being static and not reliant on or susceptible to outside parameters, anyone seeking to compromise the content returned would need to do so either through the gateway or through the DNS provider. And as any effect in the former would be negated for any traffic that utilises another gateway (or their own node), this leaves only the DNS provider as a potential vector for compromise. dynode is therefore effectively ‘unhackable’.
In having the site form as a static object cached and served through servers that aren’t under my control (along with the absence of any scripts), dynode is stripped of both a critical and defining point of Web 2.0: its access to analytics, and thus, the ability the predict and direct user behaviour based on assessment of page and session metrics. I had in fact hoped to have been provided a minimal form of this via DNS with the ‘comprehensive analytics dashboard’ which Namecheap had promised me during the period I’d registered, but this was something on which they had apparently never delivered.
But even this assumes the (unnecessary) access of dynode via public IPFS gateways, and not local nodes.
The matter of dynode’s ‘websitehood’ ultimately extends to the practical as well as the ideological. When, for example, including domain links to dynode on graphs or other images I make for the site, I do not include the “http://” segment that would typically be found at the start of a Web URL, or Internet addresses in general. Not only does this illustrate the accessibility of dynode via other protocols, but it also rejects the implied primacy in HTTP as a valid means of communication and information management.
tl;dr Well yes, but actually no.
Subdomains
Here are a few subdomains I maintain, most of them also being simple redirects to IPFS objects:
diversity.dynode.io - A
collection of studies and articles on the ‘benefits’ of ethnic and
cultural plurality.
sig.dynode.io - My GPG key
signature of the current IPFS object string to which
'dynode.io' is pointed.
twitter.dynode.io - My Twitter
account.
Plans for the future
In the short term, I’m both looking into extra functionality that dynode and readers could benefit from without causing too much bloat (such as RSS feeds). I’m also considering protocols beyond HTTP & IPFS through which to serve the site, and will likely document some of these processes too.
In the longer term I am exploring alternative DNS options, in the likely event that existing providers either kick me from their services or have their ICANN accreditation revoked. If this were to happen sooner than expected, then I would be forced to expedite the process - making dynode a fully-distributed platform.
