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.
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.
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.
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.
This one will take a little longer.
The pages of dynode are written in the Markdown implementation of Pandoc, with articles, data, and image files separated by directory (/a, /d, 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 mirrored on Pinata, which is peered to both the official ipfs.io gateway, and that of Cloudflare - both of which I then load the object through, to make sure it gets cached by both, and thus is widely and quickly accessible. The object is also mirrored in a (currently) private 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 gateways instead (which by default gave 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 (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 unwise - alas, 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.
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 Net 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.
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.
In the short term, I’m both looking into extra functionality that dynode and readers could benefit from without causing too much bloat (e.g. RSS and changelogs), while also for convenience’s sake, working on further automating the writing / editing / publishing process - by say, refitting the Pandoc script to handle the intial uploads to Pinata’s API (which I will probably share). 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.
