<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Data Roads Foundation, The Blog</title>
	<atom:link href="http://www.dataroads.org/blog/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.dataroads.org/blog</link>
	<description>All roads should lead to all people.</description>
	<lastBuildDate>Sat, 14 Jan 2012 07:00:04 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>The imbalance toward profiteer networks</title>
		<link>http://www.dataroads.org/blog/2011/12/08/the-imbalance-toward-profiteer-networks/</link>
		<comments>http://www.dataroads.org/blog/2011/12/08/the-imbalance-toward-profiteer-networks/#comments</comments>
		<pubDate>Fri, 09 Dec 2011 05:00:32 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Checks and Balances]]></category>
		<category><![CDATA[broadband]]></category>
		<category><![CDATA[community]]></category>
		<category><![CDATA[Local Self Reliance]]></category>
		<category><![CDATA[monopolists]]></category>
		<category><![CDATA[municipal]]></category>
		<category><![CDATA[networks]]></category>
		<category><![CDATA[Oligopoly]]></category>
		<category><![CDATA[profiteer]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=33</guid>
		<description><![CDATA[From Community Broadband Networks, and the Institute for Local Self Reliance:]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.muninetworks.org/content/nc-labeled-tech-turkey-bill-killing-community-broadband" title="NC Labeled a "Tech Turkey" For Bill Killing Community Broadband" target="_blank"><br />
From Community Broadband Networks, and the Institute for Local Self Reliance: <br />
<img src="http://www.muninetworks.org/sites/www.muninetworks.org/files/600-TWC-Salisbury-infographic3.png" alt="Time Warner vs. Salisbury, via muninetworks.org" /></a><br />
<br />
<object width="640" height="360"><param name="movie" value="http://www.youtube.com/v/BD5sU9zxGsw&#038;rel=0&#038;hl=en_US&#038;feature=player_embedded&#038;version=3"></param><param name="allowFullScreen" value="true"></param><param name="allowScriptAccess" value="always"></param><embed src="http://www.youtube.com/v/BD5sU9zxGsw&#038;rel=0&#038;hl=en_US&#038;feature=player_embedded&#038;version=3" type="application/x-shockwave-flash" allowfullscreen="true" allowScriptAccess="always" width="640" height="360"></embed></object></p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2011/12/08/the-imbalance-toward-profiteer-networks/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>DIDO Disappointment</title>
		<link>http://www.dataroads.org/blog/2011/09/10/dido-disappointment/</link>
		<comments>http://www.dataroads.org/blog/2011/09/10/dido-disappointment/#comments</comments>
		<pubDate>Sat, 10 Sep 2011 08:21:46 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Checks and Balances]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=32</guid>
		<description><![CDATA[http://www.theregister.co.uk/2011/08/01/dido_snake_oil_or_saviour/ The Rearden Labs whitepaper on &#8220;Distributed Input Distributed Output&#8221; (DIDO) wireless technology has disappointed me in many ways. &#160; 1. First, it didn&#8217;t really talk about the technology used. Based on the single-antenna description provided, I&#8217;m guessing it uses a starter ping in the target frequency to characterize all the local reflections, kind of [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.theregister.co.uk/2011/08/01/dido_snake_oil_or_saviour/">http://www.theregister.co.uk/2011/08/01/dido_snake<wbr>_oil_or_saviour/</wbr></a></p>
<p>The Rearden Labs whitepaper on &#8220;Distributed Input Distributed Output&#8221; (DIDO) wireless technology has disappointed me in many ways.</p>
<p>&nbsp;</p>
<p><strong>1. First, it didn&#8217;t really talk about the technology used.<br />
</strong></p>
<p>Based on the single-antenna description provided, I&#8217;m guessing it uses a starter ping in the target frequency to characterize all the local reflections, kind of like sonar. The client antenna may even communicate the reflection pattern seen back via some older wireless technology, like WiFi. Signals after that initial ping are just patterned based on the reflection map, to hit the receiver all at once. Depending on the reflection space size and frequency used, the signal pattern from the source may not even resemble a traditional radio signal, but the result on the receiving end where the reflections converge would be as unmistakable as the Morse Code blip of a telegraph. A MIMO antenna array could use beam-forming to generate a unique reflection pattern in every direction, and each beam individually could fall well below FCC regulated power maximums, yet combine into a powerful (high SNR) signal at the receiver end (and only very near the receiver &#8212; within the reception bubble mentioned in the whitepaper).</p>
<p>&nbsp;</p>
<p><strong>2. The business model seems opportunistic, not technologically necessary.</strong></p>
<p>If the DIDO processing is so difficult that it needs the old centralized/mainframe computation business model to support it, then how will it ever be cost effective? I think the real answer is that the processing isn&#8217;t actually that difficult. A &lt;$500 PC can render realistic 3D environments, and it can probably perform all the same math as any Rearden Lab prototype machine. Investors are just looking for ways to force DIDO &#8220;users&#8221; into a high-margin subscription (read: perpetual servitude) model, instead of offering any low-margin commodity hardware model.</p>
<p>Hey Rearden Labs: the &#8220;low-margin commodity hardware model&#8221; worked for 3M! You should be aiming for ubiquity, not punishing your consumers.</p>
<p>&nbsp;</p>
<p><strong>3. The &#8220;snake oil&#8221; fears are easily diffused: tell the whole truth.</strong></p>
<p>The real lie is the one that sustains the whole wireless industry, from AM/FM radio to cell phone subscriptions &#8212; the claim that radio interferes. Radio is just a form of light outside human visible range. We know light does not interfere, otherwise that camera obscura inside your head (the eye) wouldn&#8217;t work. Light passes through distinct points in space unperturbed &#8212; including your own pupils &#8212; every single day! If light interfered, you couldn&#8217;t read these words right now. The problem isn&#8217;t radio &#8212; it&#8217;s your stupid antenna. Take a single rod or even cone out of your eye&#8217;s retina, stick it outside its protective enclosure, and it will see just as badly as any TV antenna. Light doesn&#8217;t interfere, but dumb antennas don&#8217;t know any better.</p>
<p>If DIDO helps rid humanity of the myth of interference, I welcome it wholeheartedly. The whitepaper makes no attempt. This is in service to its writers&#8217; goals: monopolizing all the counter-myth benefits.</p>
<p>The Register writer Richard Chirgwin is right to be suspicious, but this article is suspicious for all the wrong reasons.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2011/09/10/dido-disappointment/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The Future of Wireless Internet</title>
		<link>http://www.dataroads.org/blog/2011/08/21/the-future-of-wireless-internet/</link>
		<comments>http://www.dataroads.org/blog/2011/08/21/the-future-of-wireless-internet/#comments</comments>
		<pubDate>Mon, 22 Aug 2011 06:09:03 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Checks and Balances]]></category>
		<category><![CDATA[Defining Data Roads]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=29</guid>
		<description><![CDATA[These articles are all related: Radio frequency is just light outside of human visible range. Light does not interfere. The myth of interference. &#160; Mapping light does not require a lens. Compound eyes Phased Array Optics Researchers develop lens-free, pinhead-size camera. &#160; Wireless, single antenna, data technology that does not &#8220;interfere&#8221; with neighboring signals on [...]]]></description>
			<content:encoded><![CDATA[<h2>These articles are all related:</h2>
<p>Radio frequency is just light outside of human visible range. Light does not interfere.</p>
<p><strong><a title="Internet architect David Reed explains how bad science created the broadcast industry." href="http://www.salon.com/technology/feature/2003/03/12/spectrum" target="_blank">The myth of interference.</a></strong></p>
<p>&nbsp;</p>
<p>Mapping light does not require a lens.</p>
<p><strong><a title="Wikipedia: Eye, Compound Eyes" href="http://en.wikipedia.org/wiki/Eye#Compound_eyes" target="_blank">Compound eyes</a></strong></p>
<p><strong><a title="Wikipedia: Phased array, Optics" href="http://en.wikipedia.org/wiki/Phased_array#Optics" target="_blank">Phased Array Optics</a></strong></p>
<p><strong><a title="The microscopic device fits on the head of a pin, contains no lenses or moving parts, costs pennies to make" href="http://www.news.cornell.edu/stories/July11/microCam.html" target="_blank">Researchers develop lens-free, pinhead-size camera.</a></strong></p>
<p>&nbsp;</p>
<p>Wireless, single antenna, data technology that does not &#8220;interfere&#8221; with neighboring signals on the same frequency is already in early stages of development.</p>
<p><strong><a title="Parsing the Perlman paper" href="http://www.theregister.co.uk/2011/08/01/dido_snake_oil_or_saviour/" target="_blank">DIDO: snake oil or wireless salvation?</a></strong></p>
<p>&nbsp;</p>
<p>Each wireless &#8220;access point&#8221; can also serve as a core router.</p>
<p><strong><a title="Wikipedia: Netsukuku" href="http://en.wikipedia.org/wiki/Netsukuku" target="_blank">Netsukuku</a></strong></p>
<p>&nbsp;</p>
<p>The Internet does not belong to the corporations.</p>
<p><strong><a title="Universal broadband should be about control, not just access." href="http://www.slate.com/id/2301435/pagenum/all" target="_blank">In Defense of the Internet Craftsman</a></strong></p>
<p>&nbsp;</p>
<p>The US Postal Service is failing in its core mission: affordable national communications.</p>
<p><strong><a title="The U.S. Postal Service must make massive changes if it is going to survive." href="http://www.slate.com/id/2301846/" target="_blank">Deliverance</a> </strong></p>
<p>&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2011/08/21/the-future-of-wireless-internet/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Why I started DataRoads.Org, and ThePoint.com Challenge.</title>
		<link>http://www.dataroads.org/blog/2010/12/29/why-i-started-dataroads-org-and-thepoint-com-challenge/</link>
		<comments>http://www.dataroads.org/blog/2010/12/29/why-i-started-dataroads-org-and-thepoint-com-challenge/#comments</comments>
		<pubDate>Wed, 29 Dec 2010 17:43:28 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Defining Data Roads]]></category>
		<category><![CDATA[Auto Club]]></category>
		<category><![CDATA[challenge]]></category>
		<category><![CDATA[Concept Flipping]]></category>
		<category><![CDATA[IPv4]]></category>
		<category><![CDATA[IPv6]]></category>
		<category><![CDATA[mesh]]></category>
		<category><![CDATA[protocols]]></category>
		<category><![CDATA[routing]]></category>
		<category><![CDATA[ThePoint.com]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=25</guid>
		<description><![CDATA[Why I started DataRoads.Org As with most truly new endeavors, this one took a path that no one could predict or intend. I really thought there would already be something like this out there, somewhere. I was surprised the DataRoads.Org domain name was even available. Even after setting up this web site, I thought all [...]]]></description>
			<content:encoded><![CDATA[<h2>Why I started DataRoads.Org</h2>
<p>As with most truly new endeavors, this one took a path that no one could predict or intend. I really thought there would already be something like this out there, somewhere. I was surprised the DataRoads.Org domain name was even available. Even after setting up this web site, I thought all that we would have to do is promote existing network standards for deployment by land and home owners, making the Data Roads Foundation more like an Auto Club and less like a civil engineering firm.</p>
<p>In fact, I thought I already knew of a couple Data Roads routing software candidates, via my research for the <a title="North East Los Angeles Internet Service Cooperative" href="http://NELA-ISC.Net/" target="_blank">NELA-ISC.Net</a> project. The main projects I had in mind were <a title="The CUWiN Foundation" href="http://www.cuwireless.net/" target="_blank">CUWiN</a> and <a title="Practical End-host collaborative Residential Multihoming" href="http://swing.cs.uiuc.edu/projects/perm/index.php" target="_blank">PERM</a>, both wireless mesh projects of the <a href="http://illinois.edu/">University of Illinois at Urbana-Champaign</a>. Unfortunately, most of the updates and action on these projects seem to have ended in 2008, due to students graduating, and Ph.D. candidates finishing their theses. They are two great open source projects to work from, but thorough research made it obvious that I would be fairly alone in updating them to the latest hardware. It also seemed like these projects were limited to small communities in scope, because of the use of <a title="Wikipedia: IPv4" href="http://en.wikipedia.org/wiki/IPv4" target="_blank">IPv4</a> addressing. <a title="Internet Corporation for Assigned Names and Numbers" href="http://www.icann.org/" target="_blank">ICANN</a> is running out of <a title="Wikipedia: IPv4" href="http://en.wikipedia.org/wiki/IPv4" target="_blank">IPv4</a> numbers this year, because they are insufficient for seamless global routing compared to <a title="Wikipedia: IPv6" href="http://en.wikipedia.org/wiki/IPv6" target="_blank">IPv6</a>.</p>
<p>I looked all over the current Internet for router projects that would meet some simple criteria: <a title="Wikipedia: IPv6" href="http://en.wikipedia.org/wiki/IPv6" target="_blank">IPv6</a> subnet with a 64-bit minimum for geographic numbering, efficient mesh topography routing in any medium (wired or wireless), and open source software support for configuration and upgrades. I looked at all available <a title="Wikipedia: Geographic Routing" href="http://en.wikipedia.org/wiki/Geographic_routing" target="_blank">geographic</a> and <a title="Wikipedia: Mesh Networking" href="http://en.wikipedia.org/wiki/Mesh_networking" target="_blank">mesh routing</a> systems mentioned in Wikipedia. I studied several University projects like those mentioned above. I looked into router firmware projects like <a href="http://openwrt.org/" target="_blank">OpenWRT</a>, <a href="http://www.dd-wrt.com/site/index" target="_blank">DD-WRT</a>, and <a title="Tomato Firmware" href="http://www.polarcloud.com/tomato" target="_blank">Tomato</a>. I read about <a title="Wikipedia: Peer-to-peer" href="http://en.wikipedia.org/wiki/Peer-to-peer" target="_blank">peer-to-peer network</a> software of all types. Nothing out there  completely fit our overall goals. Projects that approximate our needs are still in the IT experts-only phase, making it too difficult to get regular people to install it for themselves.<br />
<br/></p>
<h2><strong>ThePoint.com Challenge</strong></h2>
<p>I studied a lot of different options for getting nonprofit startups bootstrapped. I bought a <a title="How to Form a 501(c)(3) Nonprofit Corporation" href="http://www.nolo.com/legal-encyclopedia/article-30228.html" target="_blank">Nolo legal</a> book on the subject, which is specifically written for California based nonprofits, but it&#8217;s applicable to most United States. I found new contacts through my Internet activism research &#8212; most helpfully <a title="MuniNetworks posts tagged Christopher Mitchell" href="http://www.muninetworks.org/tags-124" target="_blank">Christopher Mitchell at MuniNetworks.org</a>, and <a href="http://www.saschameinrath.com/" target="_blank">Sascha Meinrath</a> at the <a title="New America Foundation: Open Technology Initiative" href="http://oti.newamerica.net/" target="_blank">Open Technology Initiative</a> of the <a href="http://www.newamerica.net/" target="_blank">New America Foundation</a> (he is also one of the co-founders of the CUWiN project mentioned above). I even joined the board of my local <a title="Eagle Rock Neighborhood Council" href="http://www.eaglerockcouncil.org/" target="_blank">neighborhood council</a>, even though it&#8217;s a <a title="Wikipedia: Neighborhood Councils" href="http://en.wikipedia.org/wiki/Neighborhood_Councils#Example:_Neighborhood_Councils_in_Los_Angeles" target="_blank">Los Angeles City Chartered municipal </a>organization, and thus not really a nonprofit. Based on research and advice, I tried to get an existing nonprofit to accept DataRoads.Org as a sponsored project. I found a few nonprofits in the Open Source and Community Network fields that seemed like good matches, but none of them are interested. I also looked into the <a href="http://www.tides.org/" target="_blank">Tides Foundation</a>, and they required $5000 minimum in donations before they would accept any application for sponsorship. If I had that kind of money to put into this on my own, the nonprofit would already be incorporated.</p>
<p>So I started a challenge on <a title="Help start the Data Roads Foundation." href="http://www.thepoint.com/campaigns/campaign-0-1606" target="_blank">ThePoint.com</a>, which is a great service for all-or-nothing challenges. Either the challenge gets completely funded to the point where it will be sustainable, or nothing happens at all, and everyone keeps their pledge money. If you really want something to happen, but don&#8217;t have all the money needed to fund it on your own, this is a way to pledge money in a way that insures it will either happen when all resources are ready, or you keep your money.</p>
<p>I have already put a lot of my resources into this web site, but I have already pledged even more to <a title="Help start the Data Roads Foundation." href="http://www.thepoint.com/campaigns/campaign-0-1606" target="_blank">ThePoint.com</a> challenge. So if you really want to see DataRoads software and hardware created, and eventually have the chance to install your own home Data Roads, please help fund <a title="Help start the Data Roads Foundation." href="http://www.thepoint.com/campaigns/campaign-0-1606" target="_blank">ThePoint.com</a> challenge. I&#8217;ll try to make sure you never regret it.</p>
<div><a style="border: 0;" href="http://www.thepoint.com/campaigns/campaign-0-1606"><img src="http://www.thepoint.com/campaigns/campaign-0-1606/badges.jpg" alt="Badges" width="195" height="90" /></a></div>
<p><object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="301" height="342" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowscriptaccess" value="always" /><param name="allownetworking" value="external" /><param name="FlashVars" value="campaignId=campaign-0-1606&amp;appUrl=http://www.thepoint.com" /><param name="src" value="http://www.thepoint.com/flash/Widget.swf?1278469253" /><param name="flashvars" value="campaignId=campaign-0-1606&amp;appUrl=http://www.thepoint.com" /><embed type="application/x-shockwave-flash" width="301" height="342" src="http://www.thepoint.com/flash/Widget.swf?1278469253" flashvars="campaignId=campaign-0-1606&amp;appUrl=http://www.thepoint.com" allownetworking="external" allowscriptaccess="always"></embed></object></p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2010/12/29/why-i-started-dataroads-org-and-thepoint-com-challenge/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The &#8220;One True&#8221; Fallacy</title>
		<link>http://www.dataroads.org/blog/2010/12/13/the-one-true-fallacy/</link>
		<comments>http://www.dataroads.org/blog/2010/12/13/the-one-true-fallacy/#comments</comments>
		<pubDate>Tue, 14 Dec 2010 06:52:25 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Checks and Balances]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=23</guid>
		<description><![CDATA[Although &#8220;The &#8216;One True&#8217; Fallacy&#8221; may eventually qualify for a list of logical fallacies, I don&#8217;t have the Ph.D. nor time required to present all the reasoning behind adding it. I really just want to talk about data files. Where is my file? There is a human tendency to need to equate digital objects with [...]]]></description>
			<content:encoded><![CDATA[<p>Although &#8220;The &#8216;One True&#8217; Fallacy&#8221; may eventually qualify for a list of <a title="The Nizkor Project: Fallacies" href="http://www.nizkor.org/features/fallacies/" target="_blank">logical fallacies</a>, I don&#8217;t have the Ph.D. nor time required to present all the reasoning behind adding it. I really just want to talk about data files.</p>
<p><span id="more-23"></span></p>
<h2>Where is <em>my</em> file?</h2>
<p>There is a human tendency to need to equate digital objects with physical ones. We often say &#8220;I have the file&#8221; even though we know perfectly well that copies of &#8220;the file&#8221; are strewn all over the Internet. If there is anyone who &#8220;has&#8221; the file as in legal ownership, then it&#8217;s probably a shadowy Copyright holding corporation somewhere, that may exist only in a government file cabinet (and that file cabinet may actually be a digital figment as well). This goes back to early human confusions with the nature of copies. In the same way we claim to &#8220;have the file&#8221;, a person just after the turn of the prior century might have claimed to &#8220;have the newspaper&#8221;, knowing full well that they only held one of many reproductions from a particular newsprint source. Just because I have a USB stick with a file stored on it, that I can hand to you, doesn&#8217;t mean I &#8220;have&#8221; any file. All I have is a digital representation of some data that you might find useful, in a medium that I can transfer to you conveniently. The &#8220;file&#8221; is the method for finding that data in a specific medium &#8212; it is not a physical thing unto itself.</p>
<h2>I <em>invented</em> language!</h2>
<p>This data=object confusion leads to a completely different sort of confusion, over where the &#8220;one true file&#8221; is. This is like finding the &#8220;one true inventor&#8221;, or the &#8220;original idea&#8221; for a new device &#8212; neither notion can be confirmed with any reliability, as the muddled history of any human patent law system shows. Ideas (and their sibling notion of data) are viral, progressive, integrative, and transmitted only through abstract communications &#8212; they are never created from nothingness, fully formed at inception, like some big-bang theory of thought. All our notions of origination are illusory.</p>
<p>Depending on who you&#8217;re talking to, this &#8220;one true file&#8221; may generally be regarded as the most popular web site where the file is available, or it may be the secret source from which this file was first propagated. The &#8220;one true&#8221; news column may thus be on a newyorktimes.com server farm, or it may be sitting in the hard drive of a desktop computer in a busy newsroom in New York &#8212; behind a firewall, far away from any server that is connected to the public web. This confusion exists even when the file you see in the web browser, the file delivered by the server, the file sitting in the writer&#8217;s desktop computer, and the files sitting in some proxy servers in between, are all an <em>exact copy</em> of the same data.</p>
<p><strong><em>[Geek Alert: Skip the following paragraph if neither Computer Science nor Information Philosophy hold any interest for you... of course if that's the case then why continue reading at all?]</em></strong></p>
<p>I&#8217;ll grant this <em>exact copy </em>case is rare, since edit file formats tend to differ from read-only display file formats, for very good reasons about the difference in uses; but those differences and reasons aren&#8217;t really germane to this discussion. I would even posit that any two files that have only one (batch) linear or pre-defined transformation step between them are the same, especially when access to said transformation steps are equal to file access; but that supposition is more technical than necessary. Let&#8217;s just say that if two humans can separately read the same text, or see the same image, even with minor variations due to monitor or equipment differences, then they are essentially viewing the same file. They also implicitly have access to the same file data, because the view mediums always require a local data copy.</p>
<p><strong><em>[End self-indulgent geekery.]</em></strong></p>
<h2>My <em>true</em> name is Fred, but <em>you</em> can call me Larry.</h2>
<p>This &#8220;one true&#8221; file fallacy extends to the naming systems of the Internet, including both the URL and URI systems we use to browse the web. Both TLA&#8217;s are short for phrases that start with the two words &#8220;uniform&#8221; and &#8220;resource&#8221;. The administrative word &#8220;uniform&#8221; is a common longhand term for concepts like &#8220;one true&#8221; or &#8220;central&#8221; way of doing things. In computer science, &#8220;resource&#8221; tends to be a shorthand for digital objects (like files). We use such misleading words because we know deep down that these computer concepts are completely made up, so words like &#8220;resources&#8221; make our roles <em>sound</em> more substantial than in reality. When any human system starts out by claiming to be &#8220;uniform&#8221; or worse &#8220;universal&#8221;, you should know that they are claiming to hold the &#8220;one true&#8221;, &#8220;central&#8221;, or &#8220;correct&#8221; way of going about things. In the case of naming systems, they are trying to provide the &#8220;one true&#8221; way to both name things, and find things via their names later.</p>
<p>I can hear one objection already &#8212; many are going to claim that by &#8220;uniform&#8221; they <em>really</em> mean something akin to the phrase &#8220;globally unique.&#8221; They start going to outer space with words like &#8220;global&#8221;, and they use such words because everybody likes space stuff, and the universe of stars is much more fun to think about than long division.  They really just mean the &#8220;unique&#8221; thing is contained with the &#8220;global&#8221; extent of the system described. So what they <em>really really </em>mean is that the name is unique to their system as a whole &#8212; past, present, and (hopefully) future. In the case of Internet &#8220;Uniform Resource Locators&#8221;, is that really true? If http://newyorktimes.com/OJstory.html and ftp://losangelestimes.com/OJstory.html are copies of the same file (let&#8217;s just say they got it from the same freelance writer), then are these files and names really &#8220;unique&#8221;? The further counter-argument I&#8217;m hearing now is that the (full path) names have to be unique in the naming system, but we don&#8217;t care about the data underneath, because we&#8217;re talking about <em>naming</em> systems not <em>full data</em> systems. Some people might even regard it as a <em>feature</em> that the same data can be found with two or more different names.</p>
<h2>Wearing the mask of identity.</h2>
<p>Let&#8217;s temporarily put all those arguments about digital files aside, and talk about something a little more obvious: digital identity. Most humans have a pretty good sense of their own identity, and know that digital information (data) about them is incomplete at best, or grossly inaccurate at worst. Sometimes the inaccuracies in our online personas are completely intentional &#8212; we don&#8217;t want them linked to our real life identities at all. Yet this is not how we treat our identity online when conveying it to people in real life.  We often say &#8220;use my email&#8221; or &#8220;find my Facebook&#8221;, as if either these diverse-open or immense-proprietary systems could be &#8220;held&#8221; or &#8220;owned&#8221; enough to use a possessive word like &#8220;my&#8221;. What we really mean is that we have some sense of <em>exclusive</em> access to these resources. Is this sense of <em>exclusivity</em> ever really true, either? As a Systems Administrator and Programmer with over 16 years in IT management roles, I can tell you this answer confidently: if it&#8217;s digital, then it&#8217;s never exclusive.</p>
<h2>The difference between <em>feeling</em> and <em>reality</em>.</h2>
<p>The best IT standards and practices can provide the <em>feeling</em> of exclusive access to your online accounts, or even <em>temporary</em> true exclusivity. If a legal or administrative need arises, then you can be sure the <em>true server owners </em>(the people with physical access to the server hardware) will feel a perfect right to access or even alter <em>your</em> data. Given this fact, can we ever say that we have &#8220;one true&#8221; identity online? My answer is: never. The best you can hope for is running your own private Internet servers, on your own private property, and hope that everyone else online defers to those servers in cases of contention. Also, even if you have the resources for all the personal property and server technology required, you better pray the servers don&#8217;t get hacked into without your knowledge. That&#8217;s a form of property protection that the Fortune 500 still haven&#8217;t mastered, so you have little hope of attaining such absolute protection as an individual.</p>
<h2>I wrote that after you did, but I posted it first!</h2>
<p>The implications of this lack of digital identity on any notion of digital &#8220;origination&#8221; or &#8220;authorship&#8221; should be obvious. Without any consistent or provable form of identity, how can you ever establish authorship?</p>
<p>It should be clear by now that everything online is a copy of something else. So the real problem is less about tracking or naming what is unique &#8212; the real problem is detecting and tracking copies. To complicate the problem: partial, imperfect, and translated copies are both useful and normal. The most common form of translation isn&#8217;t even between human languages &#8212; it&#8217;s between computer software formats. Some of these translations are perfectly reversible, where a perfect copy of the &#8220;original&#8221; data can be derived from the translated version. Microsoft Office DOC files, DOCX files, OpenOffice.org ODT files, and even PDF and HTML files are all interchangeable, based on the available translation tools that can go back and forth between these different formats. It&#8217;s all just text data, with slightly different ways of representing formatting.</p>
<h2>I&#8217;ll send that to you again, even though it&#8217;s a waste of time and energy.</h2>
<p>So how do we track all these copies, in a way that prevents waste? The biggest forms of waste online don&#8217;t involve storage space, because storage is plentiful, cheap, and low power. The biggest waste is transferring the same data over the same network repeatedly, or from farther away than necessary. The bandwidth and power wasted are tremendous. In my previous post titled &#8220;When Global Agreements Aren&#8217;t Necessary&#8221;, I posited a general method of naming things online without any central authority like ICANN or IANA required. I&#8217;m going a different route with copy-tracking, but the only authority needed is the &#8220;original&#8221; author of any given set of data. This wont prevent people from &#8220;forking&#8221; or altering data to misrepresent origins, but we can track the &#8220;originator&#8221; ID conveniently enough that bothering to alter it will seem like it&#8217;s not worth the time or trouble. The ability to trace a file to its origins can also be intrinsically linked with a social sense of authenticity. When translations between different formats and languages are involved, we can simply track the translator along with the data source. If a reversal procedure is available for any translator, we can simply use that reverse process to get back to the source data, without needing to waste network resources by retrieving it separately.</p>
<h2>Y&#8217;arr matey! Did I already say that? No? Good. Y&#8217;arrrrr&#8230;.</h2>
<p>So how do we keep all this information, like translators and &#8220;originator&#8221; or &#8220;owner&#8221; IDs, with diverse copies of all these files? The necessary concept is already being used with the better journaling file systems available, and it comes from naval tradition: a manifest. A ship manifest is not the ship, but a log of all information concerning the travels, cargo, and crew of a ship. A file manifest is like a log of all meta-data, or data that is only about a file &#8212; how/where/when the data in a file has been created, how/where/when it has changed, and everywhere it has traveled. The file name, contents, and hardware location could all change, yet the top of the manifest (the &#8220;unique&#8221; object and origination ID) would stay the same for every copy. The best manifest data would be considered read-only, and new manifest data would be append-only (just like the best logs in general).</p>
<p>Any two people with access to the same top manifest copies would know they have access to a file from the same source, and it would just take a little coordination to resolve differences between their two copies. Such coordination would eliminate the need for sending the whole file copies back and forth. For example, one person might have the same exact manifest up to a certain date, and thus recreating the steps described in the manifest with the newer dates is all that is needed, to resolve the two differing versions of the same file to the same state. File changes from the matching manifest date onward, and not the <em>whole</em> file, could be sent to reproduce an exact copy of the same file data. By avoiding retransferring the whole file, time and resources are saved in the process. When all potential transfer sources are known, the file changes can also be sent from only the nearest sources, saving even more latency time and transmission resources. The speed of light is a limit that can only be overcome with proximity.</p>
<h2>It is time to unlearn what you have learned.</h2>
<p>So this is all to say that, I think we have been taught something wrong about files and data: that the &#8220;uniform&#8221; or &#8220;unique&#8221; name is the most important detail. Obviously the data itself is the most important aspect of any file, but that data is too abstract to consistently track by humans. It&#8217;s like trying to track all the crabs in a crab trawler by memorizing each and every crab&#8217;s appearance &#8212; it&#8217;s an impossible task for humans. We have tried labeling the crabs, the crates, and the trawlers, but they all keep on reproducing and spreading to new seas, untracked and unabated. The names we gave them don&#8217;t help us to identify the reproductions as apart from the originals, nor that they&#8217;re even related to the originals. Instead we should acknowledge that these names we&#8217;re giving everything are all transitory and illusory. Instead, we should form consistent manifest standards, that every trawler captain can consistently apply, and then stick to them.</p>
<p>256 binary bits are sufficient to uniquely enumerate all the atoms in the known universe. Knowing that, with something like a random cryptographic 256-bit (32-byte) originator and object ID at the top of every manifest, we could consistently and efficiently track every file ever produced. With these manifest standards, notions of &#8220;origination&#8221; have become much more straightforward to trace, and become less tied to specific servers and timing. The manifest thus frees the data &#8212; letting each file become more traceable, yet without the bonds of any &#8220;uniform&#8221; naming conventions. The act of naming things, after all, is a matter of human convenience, not of creating any true persistent identity. A manifest history is much closer to the ideal of tracing identity, which is the true goal of naming.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2010/12/13/the-one-true-fallacy/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Power over DataRoads: Energy competition through microgrids.</title>
		<link>http://www.dataroads.org/blog/2010/11/08/power-over-dataroads-energy-competition-through-microgrids/</link>
		<comments>http://www.dataroads.org/blog/2010/11/08/power-over-dataroads-energy-competition-through-microgrids/#comments</comments>
		<pubDate>Mon, 08 Nov 2010 22:41:38 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Checks and Balances]]></category>
		<category><![CDATA[Defining Data Roads]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=21</guid>
		<description><![CDATA[Recent developments in small renewable power sources (like solar and small wind), as well as infrastructure destruction during recent tragedies (like Hurricane Katrina), have led some brilliant minds to rethinking the way we distribute and manufacture electrical power. Many of these studies all lead to the same conclusion: data networks allow us to carry enough [...]]]></description>
			<content:encoded><![CDATA[<p>Recent developments in small renewable power sources (like solar and small wind), as well as infrastructure destruction during recent tragedies (like <a href="http://www.sciencedaily.com/releases/2008/07/080722152609.htm" target="_blank">Hurricane Katrina</a>), have led some brilliant minds to rethinking the way we distribute and manufacture electrical power. Many of these studies all lead to the same conclusion: data networks allow us to carry enough information about diverse power sources and uses, so that they can be efficiently coordinated at small scale, over a simple grid of neighbor-to-neighbor transmission lines. These small power grids are generally called <a title="Peer-to-peer power through microgrids" href="http://knowledgeproblem.com/2009/04/21/peer-to-peer-power-through-microgrids/" target="_blank">microgrids</a>. These &#8220;smart power&#8221; grid networks function at fairly low data bandwidth, so <a title="Wikipedia: Smart grid" href="http://en.wikipedia.org/wiki/Smart_grid" target="_blank">smart grids</a> can be built on top of (or to extend) normal network data lines.</p>
<p><span id="more-21"></span></p>
<p>Existing power-over-data line technologies already exist. One common standard is <a href="http://www.poweroverethernet.com/" target="_blank">Power over Ethernet (PoE)</a>. This powerful technology standard is already used to power network devices, like wireless access points and cameras, to minimize the wiring required to connect these high-bandwidth devices. These safe power/data lines have been shown to carry as much as <a title="High Power PoE Gets Even Higher" href="http://www.poweroverethernet.com/poe-plus-products.php" target="_blank">95 Watts</a> &#8212; far more than the power needed for any one small network device. This excess power can be used for common household appliances and computers instead, to offset the power needed from an aging utility infrastructure. Unused power can also be stored in batteries nearby, ready when needed. PoE lines use <a title="Wikipedia: Direct Current" href="http://en.wikipedia.org/wiki/Direct_current" target="_blank">Direct Current</a> power, which is much more compatible with most modern renewable power sources, batteries, and computer technologies than North American utility <a title="Wikipedia: Alternating Current" href="http://en.wikipedia.org/wiki/Alternating_current" target="_blank">Alternating Current</a>.</p>
<p><a title="Defining Data Roads" href="/blog/category/defining-data-roads/" target="_self">DataRoads</a> are to data transmission what microgrids are to power transmission. By using existing and future wire standards like PoE, the same equipment can be used for both DataRoads communications and microgrids power, all over the same lines and equipment. Peripherals like batteries and solar panels can then be used for much more than DataRoads backup power &#8212; they could be used to power wall outlets and attached network devices, to keep everything running during utility brown- and black-outs. Install the lines you need along your fence once, share those lines with your neighbors, and suddenly you can share electricity as well as voice, video, and files. Power over <a title="Flipping the Internet Upside Down, Visually" href="/blog/2010/08/17/flipping-the-internet-upside-down-visually/" target="_self">DataRoads</a> replaces two outdated <a title="The Internet As An Appliance" href="/blog/2010/07/19/the-internet-as-an-appliance/" target="_self">utility subscription models</a>, with only one set of hardware.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2010/11/08/power-over-dataroads-energy-competition-through-microgrids/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Flipping the Internet upside-down, visually.</title>
		<link>http://www.dataroads.org/blog/2010/08/17/flipping-the-internet-upside-down-visually/</link>
		<comments>http://www.dataroads.org/blog/2010/08/17/flipping-the-internet-upside-down-visually/#comments</comments>
		<pubDate>Wed, 18 Aug 2010 00:42:54 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Defining Data Roads]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=16</guid>
		<description><![CDATA[I&#8217;ve rarely been accused of being too terse, or not technical enough. In the interest of brevity and clarity, I have created a visual representation of how it looks to flip the Internet upside-down, as suggested solely via text in an earlier post. This may not be the prettiest possible illustration of the Internet hierarchy [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve rarely been accused of being too <a title="The Internet as an appliance." href="/blog/2010/07/19/the-internet-as-an-appliance/" target="_self">terse</a>, or not <a title="When global agreements are not necessary." href="/blog/2010/08/11/when-global-agreements-arent-necessary/" target="_self">technical enough</a>. In the interest of brevity and clarity, I have created a visual representation of how it looks to flip the Internet upside-down, as suggested solely via text in an<a title="Flipping the Internet upside-down." href="/blog/2010/06/26/flipping-the-internet-upside-down/" target="_self"> earlier post.</a></p>
<p><a href="http://www.dataroads.org/blog/wp-content/uploads/2010/08/Internet_flip_illustrated.png"><img class="aligncenter size-full wp-image-17" title="Internet_flip_illustrated" src="http://www.dataroads.org/blog/wp-content/uploads/2010/08/Internet_flip_illustrated.png" alt="Internet flip, illustrated." width="600" height="849" /></a></p>
<p><span id="more-16"></span></p>
<p>This may not be the prettiest possible illustration of the Internet hierarchy flip intended by the Data Roads Foundation, but hopefully it is at least clear. All of the company logos were taken from the <a title="FreePress.net -- Ownership Chart: The Big Six" href="http://www.freepress.net/ownership/chart/main" target="_blank">FreePress.net Media Ownership</a> pages. <a title="Ownership Chart: The Big Six" href="http://www.freepress.net/ownership/chart/main" target="_blank">The Big 6</a> content companies are floating inside the Internet cloud on top, but they fall to the bottom once DataRoads.Org infrastructure is in place, vying to connect to the new cloud owners (us!).  The <a title="FreePress.net -- Ownership Chart: Telecommunications" href="http://www.freepress.net/ownership/chart/telecom" target="_blank">top 6 Internet access controllers</a> hover in the middle, currently standing as a gateway between all of us and the wider Internet. After DataRoads.Org connections between us are finally complete, these same networks lay with the content companies in the bottom, all vying for better connections into <em>our </em>cloud. At this point, if these descending titans failed to connect into our DataRoads cloud(s), they wouldn&#8217;t have a prayer of keeping their business customers interested in their networks. You can see the content corporations finding ways to get around these failed gatekeepers, to connect to all of us (their customers) more directly.</p>
<p>If you find my illustration ugly at all, take that as a personal challenge: draw one better! The illustration and all its constituent pieces should be considered public domain. The <a title="Gate clip art" href="http://www.clker.com/clipart-gate.html" target="_blank">castle gates</a> and <a title="Iron Gate clip art" href="http://www.clker.com/clipart-52143.html" target="_blank">iron gate</a> illustrations were found at a site for public domain clip art, <a title="Clkr.com" href="http://www.clker.com/" target="_blank">Clkr.com</a>. Other than the company logos from <a title="FreePress.net -- Ownership Chart: The Big Six" href="http://www.freepress.net/ownership/chart/main" target="_blank">FreePress.net</a>, I drew everything else myself, and you are free to use it all. You can even use the original <a title="Inkscape -- An Open Source vector graphics editor." href="http://www.inkscape.org/" target="_blank">Inkscape</a> <a title="Internet_flip_illustrated.svg Inkscape SVG format" href="/media/Internet_flip_illustrated.svg">SVG</a>, or the <a title="Internet_flip_illustrated.svg compressed plain SVG format" href="/media/Internet_flip_illustrated.svgz">compressed plain SVG format</a>. You can also use the <a title="Internet_flip_illustrated.pdf exported for print." href="/media/Internet_flip_illustrated.pdf">PDF I exported</a>, which might be easiest if you want to print it out and hand-draw anything on it.</p>
<p>Maybe we will hold a contest for the best &#8220;Internet flip&#8221; illustration! Use the comments here to enter, or to apply to be a judge.  Remember to give us your valid email address in your comment profile &#8212; it wont be shared with anyone else, and your entry will be invalid without it. All entrants must assign full rights to the Data Roads Foundation and its current officers to use or re-license the illustration however we please (preferably <a title="CreativeCommons Attribution 2.0 Generic" href="http://creativecommons.org/licenses/by/2.0/" target="_blank">CC-BY</a>). The winner will earn a permanent place in the illustration credits, and in our hearts.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2010/08/17/flipping-the-internet-upside-down-visually/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Connection Rights and a First-Sale Doctrine for Broadband</title>
		<link>http://www.dataroads.org/blog/2010/08/15/connection-rights-and-a-first-sale-doctrine-for-broadband/</link>
		<comments>http://www.dataroads.org/blog/2010/08/15/connection-rights-and-a-first-sale-doctrine-for-broadband/#comments</comments>
		<pubDate>Sun, 15 Aug 2010 18:16:00 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Checks and Balances]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=15</guid>
		<description><![CDATA[These legislative propositions came to me as ideas that would ease Data Road equipment deployment in the future, but I think they could have a good (but more subtle) effect on their own, and with Network Neutrality legislation in general. Let me know if you agree. Connection Rights Lines from utility poles and conduits within right-of-way spaces invariably cross into [...]]]></description>
			<content:encoded><![CDATA[<p>These legislative propositions came to me as ideas that would ease Data Road equipment deployment in the future, but I think they could have a good (but more subtle) effect on their own, and with Network Neutrality legislation in general. Let me know if you agree.</p>
<p><span id="more-15"></span></p>
<h3>Connection Rights</h3>
<p>Lines from utility poles and conduits within right-of-way spaces invariably cross into private property at some point. There is a tacit agreement that the property holder will not charge a rent for this space, in return for access to the services that the utility line provides. In balance with this existing yet unspoken agreement, the property owners should have the right to connect their own lines back to the pole or right-of-way conduit that connects through their property, at no charge. If an attempt at a rental charge is made, the property owner has the right to counter-charge for rental of space for lines traversing their property, thus cancelling out all potential rents from both ends.</p>
<p>Further, if an agreement can be made between two separate property holders within 2 degrees of connection (2 poles or right-of-way spaces separate them at most), they have the right to jointly utilize their separate connection rights to connect directly with each other, over the shared set of means. They will naturally have to obey any state and federal regulatory restrictions on the line types and installation methods used. The restriction of 2-degree separation or below should keep the structural and financial impacts of these direct connections on utility infrastructure to a minimum.</p>
<h3>First-Sale Doctrine for Broadband</h3>
<p>In the same way that first-sale doctrine implicitly grants product consumers the ability to resell items that are not currently being used, like used books and discs &#8212; bandwidth subscribers should have the implicit right to resell or share unused capacity. Unsigned and ill considered &#8220;<em>Terms of Use</em>&#8221; agreements generally prohibit such resell, and are currently dictated to most broadband subscribers by providers at sign-up without their consultation or any forewarning. All such subscription contract terms or resell prohibitions should be stricken as unlawful, void, and unenforceable.</p>
<p>The test for maximum bandwidth capacity available for resell should be held to advertised bandwidth speeds, to prevent providers from making false statements about their subscription service provision. A book seller can&#8217;t advertise a whole book at one price, and then only give you half the book for the same advertised price. The same should hold true for broadband sellers.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2010/08/15/connection-rights-and-a-first-sale-doctrine-for-broadband/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>When global agreements aren&#8217;t necessary.</title>
		<link>http://www.dataroads.org/blog/2010/08/11/when-global-agreements-arent-necessary/</link>
		<comments>http://www.dataroads.org/blog/2010/08/11/when-global-agreements-arent-necessary/#comments</comments>
		<pubDate>Thu, 12 Aug 2010 07:46:50 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Checks and Balances]]></category>
		<category><![CDATA[Defining Data Roads]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=12</guid>
		<description><![CDATA[I want to eliminate the need for ICANN &#8212; the group that decides all the Internet names! Did that get your attention? That&#8217;s good, but please note that I would like to have ICANN around for a very long time. The operative word in that first sentence is &#8216;need.&#8217; I want to eliminate the need [...]]]></description>
			<content:encoded><![CDATA[<p><strong>I want to eliminate the need for ICANN &#8212; the group that decides all the Internet names! </strong>Did that get your attention? That&#8217;s good, but please note that I would like to have ICANN around for a very long time. The operative word in that first sentence is &#8216;<em>need</em>.&#8217; I want to eliminate the <em>need </em>for ICANN, in the same way I want to eliminate the <em>need </em>for any world atlas when I&#8217;m only travelling just a few blocks away. While an atlas <em>may </em>be detailed enough to be useful for such a short trip, it&#8217;s definitely more cumbersome than necessary. I don&#8217;t even need to know the name of the city I&#8217;m in, if I&#8217;m only travelling along 1 street, just 2 blocks to the south. I could change city borders during that trip, and I wouldn&#8217;t need to realize it, unless there happened to be a wall at the city border line. In that strange case, the wall should have a plaque or guard that tells me about the city border. I don&#8217;t need the atlas if I can just read the plaque when I get there.</p>
<p><span id="more-12"></span></p>
<p><strong>So how do we name things without agreeing on the names ahead of time?</strong> Simple &#8212; when I&#8217;m looking for something, my name trumps yours. When you&#8217;re looking for something, your name trumps mine. No need for bickering about it, because both of our names work for us, the way we each want them to. We only have to agree on names when we want to consistently label the same thing from our different vantage points. If you have a name for something and I don&#8217;t, I can just simply use your name, rather than going through the work of making up my own. I can also just make my own aliases to the same thing later.</p>
<p><strong>Here&#8217;s a series of examples to clarify my point. </strong>I&#8217;m just going to assume here that the address systems overall resemble UNIX file systems, which look like this:</p>
<pre>/top_directory/sub_directory/sub_sub_directory/file</pre>
<p>Now what I&#8217;m looking for is not a directory or file &#8212; it&#8217;s an online service of some sort. For example, under the current ICANN way of naming things, everyone looking for the Google search service would just use &#8220;google.com.&#8221; &#8220;Com&#8221; is a top level domain for all corporations, and &#8220;Google&#8221; is the domain name of that particular search corporation. Doesn&#8217;t the word <em>domain </em>sound so&#8230; feudal? Even if you worked inside Google, you still might have to use &#8220;Google.com,&#8221; unless you know the server IP number. That IP number takes longer to type than &#8220;Google.com,&#8221; so there&#8217;s no real point in using anything but the domain name.</p>
<p>In this new non-ICANN naming system example, I&#8217;m just looking for my own online service, which I host on a server box inside my own apartment. Here&#8217;s the name path to the server of that service:</p>
<pre>/</pre>
<p>That &#8216;/&#8217; essentially means &#8220;start at the top, and go no further.&#8221; I can stop right at the top, because in <em>my </em>naming system, my own services always come first! This address path or naming system wouldn&#8217;t work for anyone else, because when they use &#8216;/&#8217; they just see their own services, not mine. At some point, we do have to reach some agreement on shared names. But the main point is that we don&#8217;t have to go all the way to a big powerful organization like ICANN to get them to agree on our own names. We just have to agree amongst each other.</p>
<p>For example, if we all live in the same apartment complex, we can agree to simply name our services according to our apartment numbers. I live in unit 6 and you live in unit 30, so either of us could use this path to get to my services:</p>
<pre>/6/</pre>
<p>I don&#8217;t have to use &#8220;6/&#8221; to get to my own service, but it works anyway, because we agreed on this name. To get to your services, we could just use this address:</p>
<pre>/30/</pre>
<p>Again, you don&#8217;t have to use &#8220;30/&#8221;, but both &#8220;/&#8221; and &#8220;/30/&#8221; work for you. Only &#8220;/30/&#8221; will work for me, because we don&#8217;t share that apartment.</p>
<p>Let&#8217;s bring another friend into this naming game, because we both want to use her online data services too. She lives down the same street, but in a different apartment complex. Her apartment number is 6, so that conflicts with my apartment name. Our complex&#8217;s street address number is 1534, and hers is 1537, so we agree to add a street number layer to our respective naming systems.</p>
<p>Her address (for us) now looks like this:</p>
<pre>/6/1537/</pre>
<p>My address looks like this to her:</p>
<pre>/6/1534/</pre>
<p>And your address looks like this to her:</p>
<pre>/30/1534/</pre>
<p>Again, neither of the residents at 1534 (you and me) need the &#8220;1534/&#8221; portion to get at services within our own complex, but these addresses work anyways. For our female friend down the street, &#8220;/6/&#8221; or &#8220;/30/&#8221; would take her to completely different services, hosted in<em> her</em> apartment complex instead of ours.  We add the street address number here for the same reason you wouldn&#8217;t tell someone who lived in a different apartment complex to &#8220;just go knock on the door of unit 6.&#8221; Their &#8220;door of unit 6&#8243; is very far away and different from yours.</p>
<p><strong>I call this user-centric naming.</strong> We, the computer &#8220;users,&#8221; are each the center of our own online universe. We can make a lot of pronoun and descriptive aliases to our own services &#8212; like &#8220;me,&#8221; &#8220;I,&#8221; &#8220;Jared,&#8221; &#8220;Apartment_6,&#8221; &#8220;cybermonkey,&#8221; etc. But we don&#8217;t have to! Anyone else can use these same pronouns for <em>them</em>selves without conflicting with <em>me</em>. The center of our online universe is each just &#8220;/.&#8221; We each start at our individual centers, and work outward from there.</p>
<p>The next apartment unit south of me is &#8220;/7/.&#8221; The next apartment building south is &#8220;/6/1532/.&#8221; The manager in that apartment set his services as the default for the complex, so I can also just use &#8220;/1532/&#8221; to get to his services. The same apartment one street west is &#8220;/6/1534/Aardvark/&#8221;. The apartment complex in the next town (with the same address otherwise) is &#8220;/6/1534/Main/Nextville/.&#8221; The apartment complex in the next state south (with the same address otherwise) is &#8220;/6/1534/Main/Myville/Louisiana/.&#8221; Most people in the U.S.A. agree you can use &#8220;LA&#8221; and &#8220;Louisiana&#8221; interchangeably, so &#8220;/6/1534/Main/Myville/LA/&#8221; works too. People who live in Myville, LA can leave the &#8220;Myville/LA/&#8221; part out if they want to. They have to use &#8220;/6/1534/Main/Myville/MS/&#8221; to get to my services, but people in our town can leave the &#8220;Myville/MS/&#8221; part out. People in a different country might have to use &#8220;/30/1534/Main/Myville/MS/USA/&#8221; to get to your services. People on another planet would use &#8220;/30/1534/Main/Myville/MS/USA/Earth/.&#8221; That address works for everyone on Earth too, but they can leave &#8220;Earth/&#8221; out if they want to avoid the extra typing.</p>
<p>Now you may be asking, what if I want to name my server &#8220;chiapet&#8221;? Go ahead! If you have other servers, like maybe &#8220;donkey&#8221;, you could choose one of the two as a <em>default </em>server that the apartment number &#8220;/30/&#8221; address goes to, instead of making your complex-mates enter &#8220;/chiapet/30/&#8221; every time. I could also make my own &#8220;chiapet&#8221; server and you would have to use &#8220;/chiapet/6/&#8221; to get to it. You could also name a server 30, so that address would be &#8220;/30/30/&#8221;. So below an address level in your control, you can add as many <em>inner layers</em> as you want. If you provide default paths that outsiders get forwarded to when they enter your basic &#8220;/apt_num/street_num/street_name/etc/&#8221; address, no one else ever has to deal with these inner layers. You could also provide direct paths to protected inner layers only to trusted friends. It&#8217;s ultimately all up to you. If people are coming to <em>your </em>services, then past a generally agreed &#8220;ownership&#8221; border, addressing is done under <em>your </em>naming system.</p>
<p><strong>One interesting aspect of having your own naming system is the ability to make your own <em>abbreviations </em></strong><strong>or <em>shortcuts</em></strong><strong>.</strong> If I don&#8217;t have a server named &#8220;foxtrot&#8221; and you do, I can set up &#8220;/foxtrot/&#8221; as an alias to your &#8220;/foxtrot/30/&#8221; server, so we both get to skip typing the &#8220;30/&#8221; part every time. I can also shorten &#8220;/Whitehouse/Washington/DC/USA/Earth/&#8221; to just &#8220;/whitehouse/.&#8221; Anyone else is free to point <em>their</em> &#8220;/whitehouse/&#8221; to any other house, preferably one painted white. You could point your &#8220;/whitehouse/&#8221; to my /whitehouse/6/&#8221; &#8212; which has the effect that your &#8220;/whitehouse/&#8221; service destination changes when mine does. We don&#8217;t all have to agree on the <em>one true whitehouse</em>, and we can each change our minds about it any time it pleases us.</p>
<p><strong>This user-centric addressing system makes ICANN&#8217;s naming bureaucracy completely unnecessary</strong>, even as just an arbitrator. You don&#8217;t need to arbitrate decisions when there&#8217;s inherently no conflict.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2010/08/11/when-global-agreements-arent-necessary/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Collective network ownership, a check on power mongers.</title>
		<link>http://www.dataroads.org/blog/2010/08/03/collective-net-v-power-mongers/</link>
		<comments>http://www.dataroads.org/blog/2010/08/03/collective-net-v-power-mongers/#comments</comments>
		<pubDate>Tue, 03 Aug 2010 20:39:42 +0000</pubDate>
		<dc:creator>Jared Hardy</dc:creator>
				<category><![CDATA[Checks and Balances]]></category>
		<category><![CDATA[Defining Data Roads]]></category>

		<guid isPermaLink="false">http://www.dataroads.org/blog/?p=10</guid>
		<description><![CDATA[I read the news too often. I say that because it&#8217;s too often depressing, which is not healthy for me. The prime example I have at the moment is this news from various sites, best summarized at BroadbandReports.com: the government is outsourcing Fourth Amendment violations to private industry. Some of the facts discussed here were [...]]]></description>
			<content:encoded><![CDATA[<p><strong>I read the news too often. </strong>I say that because it&#8217;s too often depressing, which is not healthy for me. The prime example I have at the moment is this news from various sites, best summarized at <a title="BroadbandReports.com" href="http://www.broadbandreports.com/" target="_blank">BroadbandReports.com</a>: <a title="Just in case you were still under the illusion that you had privacy online..." href="http://www.dslreports.com/shownews/Project-Vigilant-Outsourced-Domestic-ISP-Snoops-109697" target="_blank">the government is outsourcing Fourth Amendment violations to private industry.</a> Some of the facts discussed here were not new to me, such as the old partnership between <a title="Declaration of Mark Klein [PDF]" href="http://www.eff.org/files/filenode/att/SER_klein_decl.pdf" target="_blank">NSA and AT&amp;T</a>, as revealed by a courageous whistle-blower in San Francisco, <a href="http://www.washingtonpost.com/wp-dyn/content/article/2007/11/07/AR2007110700006.html">Mark Klein</a>. Inquiries over projects related to the NSA codename <a title="Wikipedia: Echelon (Signals Intelligence)" href="http://en.wikipedia.org/wiki/Echelon_(signals_intelligence)" target="_blank">ECHELON </a>have been public since 2000. Our defenders at the <a title="Electronic Frontier Foundation" href="http://eff.org/" target="_blank">Electronic Frontier Foundation (EFF)</a> and <a title="American Civil Liberties Union" href="http://www.aclu.org/" target="_blank">American Civil Liberties Union (ACLU)</a> are still <a title="EFF and ACLU Planning to Appeal Dismissal of Dozens of Spying Cases" href="http://www.eff.org/press/archives/2009/06/03" target="_blank">fighting for our rights to privacy from these corporate-government collaborative invasions.</a></p>
<p><span id="more-10"></span></p>
<p><strong>The only concern I understand about </strong><a title="Wikipedia: Network Neutrality" href="http://en.wikipedia.org/wiki/Network_neutrality" target="_blank"><strong>Network Neutrality</strong></a><strong> is the fear that it will become a tool for government intrusion</strong> into our private communications. All the stories above should tell you it&#8217;s far too late to be worried about that &#8212; that intrusion<em> has already happened</em>. The truth is that Network Neutrality only requires one provision to <strong><em>better</em></strong><strong> </strong>protect us from the government invasion we are already experiencing today: a prohibition from discriminately throttling or altering encrypted traffic. That is fairly covered by FCC Chairman Julius Genachowski in his latest additions <a title="FCC &quot;Four Freedoms&quot; policy statement, 2005 [PDF]" href="http://fjallfoss.fcc.gov/edocs_public/attachmatch/FCC-05-151A1.pdf" target="_blank">to the existing Network Neutrality rules:</a> <a title="FCC Chairman wants network neutrality, wired and wireless" href="http://arstechnica.com/tech-policy/news/2009/09/fcc-chairman-wants-network-neutrality-wired-and-wireless.ars" target="_blank"> non-discrimination and transparency</a>. Even just implementing comprehensive network management transparency is sufficient for our purposes, because encrypted protocols could be coded around the stated traffic management issues. Of the two additions, non-discrimination is probably the easiest for the FCC to actually enforce. Preventing discrimination against encrypted data would sustain our privacy.</p>
<p><strong>There remain concerns that the FCC will be unable (or as the period from 2001-2007 shows, unwilling) to enforce encryption-preserving Network Neutrality</strong> in the future. Their new &#8220;<a title="FCC &quot;Third Way&quot; Compromise Challenged" href="http://www.pcworld.com/businesscenter/article/195848/fcc_third_way_compromise_challenged.html" target="_blank">third way</a>&#8221; approach to interpreting the <a title="Telecommunications Act of 1996" href="http://www.fcc.gov/telecom.html" target="_blank">1996 Telecommunications Act</a>, after all, was a reaction to <a title="http://boingboing.net/2010/04/06/fcc-loses-big-in-cou.html" href="http://boingboing.net/2010/04/06/fcc-loses-big-in-cou.html" target="_blank">losing at their first attempt at Network Neutrality enforcement in court</a>. Despite the general acknowledgement that lax regulatory enforcement created the current American decline, in everything from finances to <a title="U.S. Ranks 23rd In Broadband Development" href="http://www.dslreports.com/shownews/US-Ranks-23rd-In-Broadband-Development-109529" target="_blank">broadband development</a>, Congress might not get their act together in time. We may have to look to new alternatives to communicate safely and privately.</p>
<p>If I create a tin-can phone, and pass one end over a shared fence line to you, then we can finally talk over a secure line. Nobody is allowed to come on our property and tap our string, without a warrant &#8212; not even AT&amp;T. We own the string, not our ISP. At least that interpretation of the <a title="Wikipedia: Fourth Amendment to the U.S. Constitution" href="http://en.wikipedia.org/wiki/Fourth_Amendment_to_the_United_States_Constitution" target="_blank">4th Amendment to the U.S. Constitution</a> is clear.  A more complicated way would be to run a VoIP network directly between our homes, with every component installed on our private property. That solution is complicated, but still technically and financially feasible. The required lines, network routers, WiFi, and VoIP equipment are already surprisingly affordable. If we&#8217;re doing that, we might as well enable everything else an IP network is capable of, including web content and video calls. If you want to converse freely, assured of your privacy when you&#8217;ve done nothing wrong, this kind of direct shared connection may soon be your <em>only </em>feasible option.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.dataroads.org/blog/2010/08/03/collective-net-v-power-mongers/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic page generated in 2.513 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2012-02-22 07:30:27 -->
<!-- Compression = gzip -->
