Discuss mailing list

[Joe Baptista <baptista AT publicroot.org>]

I was an administrator on fidonet. It was a good system. I miss it.

But good news. I am tired of trying to find wikileaks and it will soon
be available as http://wikileaks.pirates/ - the zone file follows:

; <<>> DiG 9.6.1-P2 <<>> wikileaks.pirates. AXFR
;; global options: +cmd
wikileaks.pirates. 7200 IN SOA localhost. root.localhost. 1200419407
14400 7200 950400 7200
wikileaks.pirates. 7200 IN NS localhost.
wikileaks.pirates. 7200 IN A 213.251.145.96
www.wikileaks.pirates. 7200 IN CNAME wikileaks.pirates

On Thu, Dec 2, 2010 at 12:56 PM, NYXFER <nyxfer AT panix.com> wrote:
> On 12/02/2010 01:47 AM, Julian DeMarchi wrote:
>
> Do explain more for those of us who were not around when FIDONET was around.
>
> I read a bit, and it states it was a email and newgroup network only.
>
> It also provided access to BBSs, which in turn provided chat, file
> upload/download facilities, and doors to things like games. Today those
> "nodes" would be websites, ftp sites, game servers, local DNS facilities,
> search engines, blogs.... etc. The services offered were state of the art in
> their day, but that does not mean a new network would have to be limited to
> old technology.
>
> The purpose here would be to produce an alternate de-centralized network.
> One immune to corporate and government censorship and control. One run for
> and by it's users in a democratic and fair manner.
>
> I am curios about your ideas.
>
> --julian
>
> OK, let me flesh this out in a bit of detail basing it very loosely on
> Fidonet.
>
> Overall, the scheme would be a totally decentralized non-commercial network
> run by it's users in a democratic and anarcho-libertarian  fashion.
> Authority is bottom up with elections as the mode.
>
> A Standards committee is set up to flesh out both the technical and
> political structure of the proposed new network.
>
> The world would be divided into Zones. We had 6 zones
>
> Zone 1 is North America
> Zone 2 is Europe, Former Soviet Union Countries, and Israel
> Zone 3 is Australasia
> Zone 4 is Latin America (except Puerto Rico)
> Zone 5 is Africa
> Zone 6 is Asia
>
> But the new network should probably have more; the number is unimportant. It
> serves to divide the world into manageable chunks.
>
> Each zone is further divided into Regions, Each Region is divided into
> Networks, Each Network is divided into Nodes, and each Node is divided into
> points (individual users/devices). The decentralization can go further
> however.
>
> To address a user an address of the form region:network:node/point is used.
> To address a resource (web site, ftp site, dns etc...) an address of the
> form region:network:node/protocol is used; to access a regional resource an
> address of the form ZONE:REGION/protocol is used IE: EU:UK/dns (which would
> resolve nodes within the UK network)
>
> So in this scheme, there is no need or desire for a world-wide name space .
> All name space is essentially local. One can have
> NA:US:NY:BROOKLYN/GOOGLE/http as well as EU:FR/GOOGLE/http.....
>
> Politically/technically; users "join" a node (join the network), which can
> be a local or a distant node depending on the wishes of the individual and
> the rules of the individual node. Joining a node requires the individual to
> agree to the overall network rules (personal use, no commercial activity, no
> spam... etc), and meet a minimum technical standard of required software. A
> user accesses all network services through his/her node. Think of the node
> as the user's ISP, or more accurately their gateway to the new network if
> you like.
>
> What follows is lifted from: http://www.z3.fidonet.org/policy4.htm with no
> modification. It lays out a basic structure. Of course, modern technology
> and the current political reality would mandate many changes, but the
> general ideas are sound. Fidonet was DNSed by a nodelist. Today, a more
> modern BIND system, also de-centralized,  probably should be implemented,
> but not necessarily so.
>
> Take what follows as a rough draft, a concept, an idea, if you will. One
> which worked quite well in it's day. If the concept were to be implemented
> in kind using modern technology, it would likely result in a network for the
> people.
>
> ======================================
>
> This policy document has been accepted by vote of the FidoNet coordinator
> structure, and is the current FidoNet policy document until superceded.
>
> (There are no differences between this version and 4.06 except the statement
> above.)
>
>
>
> 1  Overview
>
> This document establishes the policy for sysops who are members of the
> FidoNet organization of electronic bulletin board systems.  FidoNet is
> defined by a NodeList issued weekly by the International Coordinator.
>
> Separate policy documents may be issued at the zone, region, or net level to
> provide additional detail on local procedures.  Ordinarily, these
> lower-level
> policies may not contradict this policy.  However, with the approval of the
> International Coordinator, local policy can be used to implement differences
> required due to local conditions.  These local policies may not place
> additional restrictions on members of FidoNet beyond those included in this
> document, other than enforcement of local mail periods.
>
>
>
> 1.0  Language
>
> The official language of FidoNet is English.  All documents must exist in
> English.  Translation into other languages is encouraged.
>
>
> 1.1  Introduction
>
> FidoNet is an amateur electronic mail system.  As such, all of its partici-
> pants and operators are unpaid volunteers.  From its early beginning as a
> few
> friends swapping messages back and forth (1984), it now (1989) includes over
> 5,000 systems on six continents.
>
> FidoNet is not a common carrier or a value-added service network and is a
> public network only in as much as the independent, constituent nodes may
> individually provide public access to the network on their system.
>
> FidoNet is large enough that it would quickly fall apart of its own weight
> unless some sort of structure and control were imposed on it.  Multinet
> operation provides the structure. Decentralized management provides the
> control.  This document describes the procedures which have been developed
> to
> manage the network.
>
>
> 1.2  Organization
>
> FidoNet systems are grouped on several levels, and administration is decen-
> tralized to correspond with these groupings.  This overview provides a
> summary of the structure; specific duties of the coordinator positions are
> given later in the document.
>
> 1.2.1  Individual Systems and System Operators
>
> The smallest subdivision of FidoNet is the individual system, corresponding
> to a single entry in the nodelist.  The system operator (sysop) formulates a
> policy for running the board and dealing with users.  The sysop must mesh
> with the rest of the FidoNet system to send and receive mail, and the local
> policy must be consistent with other levels of FidoNet.
>
> 1.2.1.1  Users
>
> The sysop is responsible for the actions of any user when they affect the
> rest of FidoNet.  (If a user is annoying, the sysop is annoying.)  Any
> traffic entering FidoNet via a given node, if not from the sysop, is consid-
> ered to be from a user and is the responsibility of the sysop.  (See section
> 2.1.3.)
>
> 1.2.1.2  Points
>
> A point is a FidoNet-compatible system that is not in the nodelist, but
> communicates with FidoNet through a node referred to as a bossnode.  A point
> is generally regarded in the same manner as a user, for example, the
> bossnode
> is responsible for mail from the point.  (See section 2.1.3.)  Points are
> addressed by using the bossnode's nodelist address; for example, a point
> system with a bossnode of 114/15 might be known as 114/15.12.  Mail destined
> for the point is sent to the bossnode, which then routes it to the point.
>
> In supporting points, the bossnode makes use of a private net number which
> should not be generally visible outside of the bossnode-point relationship.
> Unfortunately, should the point call another system directly (to do a file
> request, for example), the private network number will appear as the
> caller's
> address.  In this way, points are different from users, since they operate
> FidoNet-compatible mailers which are capable of contacting systems other
> than
> the bossnode.
>
>
> 1.2.3  Networks and Network Coordinators
>
> A network is a collection of nodes in a local geographic area, usually
> defined by an area of convenient telephone calling.  Networks coordinate
> their mail activity to decrease cost.
>
> The Network Coordinator is responsible for maintaining the list of nodes for
> the network, and for forwarding netmail sent to members of the network from
> other FidoNet nodes.  The Network Coordinator may make arrangements to
> handle
> outgoing netmail, but is not required to do so.
>
> The Network Coordinator is appointed by the Regional Coordinator.
>
> 1.2.3.1  Network Routing Hubs
>
> Network Routing Hubs exist only in some networks.  They may be appointed by
> the Network Coordinator, in order to assist in the management of a large
> net-
> work.  The exact duties and procedures are a matter for the Network
> Coordina-
> tor and the hubs to arrange, and will not be discussed here, except that a
> network coordinator cannot delegate responsibility to mediate disputes.
>
> 1.2.4  Regions and Regional Coordinators
>
> A region is a well-defined geographic area containing nodes which may or may
> not be combined into networks.  A typical region will contain many nodes in
> networks, and a few independent nodes which are not a part of any network.
>
> The Regional Coordinator maintains the list of independent nodes in the
> region and accepts nodelists from the Network Coordinators in the region.
> These are compiled to create a regional nodelist, which is then sent to the
> Zone Coordinator.  A Regional Coordinator does not perform
> message-forwarding
> services for any nodes in the region.
>
> Regional Coordinators are appointed by the Zone Coordinator.
>
>
> 1.2.5  Zones and Zone Coordinators
>
> A zone is a large geographic area containing many regions, covering one or
> more countries and/or continents.
>
> The Zone Coordinator compiles the nodelists from all of the regions in the
> zone, and creates the master nodelist and difference file, which is then
> distributed over FidoNet in the zone.  A Zone Coordinator does not perform
> message-forwarding services for any nodes in the zone.
>
> Zone Coordinators are selected by the Regional Coordinators in that zone.
>
>
> 1.2.6  Zone Coordinator Council
>
> In certain cases, the Zone Coordinators work as a council to provide advice
> to the International Coordinator.  The arrangement is similar to that
> between
> a president and advisors.  In particular, this council considers inter-zonal
> issues.  This includes, but is not limited to: working out the details of
> nodelist production, mediating inter-zonal disputes, and such issues not
> addressed at a lower level of FidoNet.
>
>
> 1.2.7  International Coordinator
>
> The International Coordinator is the "first among equals" Zone Coordinator,
> and coordinates the joint production of the master nodelist by the Zone
> Coordinators.
>
> The International Coordinator acts as the chair of the Zone Coordinator
> Council and as the overseer of elections -- arranging the announcement of
> referenda, the collection and counting of the ballots, and announcing the
> results for those issues that affect FidoNet as a whole.
>
> The International Coordinator is selected by the Zone Coordinators.
>
>
> 1.2.8  Top-down Organization.  Checks and Balances.
>
> These levels act to distribute the administration and control of FidoNet to
> the lowest possible level, while still allowing for coordinated action over
> the entire mail system.  Administration is made possible by operating in a
> top-down manner.  That is, a person at any given level is responsible to the
> level above, and responsible for the level below.
>
> For example, a Regional Coordinator is responsible to the Zone Coordinator
> for anything that happens in the region.  From the point of view of the Zone
> Coordinator, the Regional Coordinator is completely responsible for the
> smooth operation of the region.  Likewise, from the point of view of the
> Regional Coordinator, the Network Coordinator is completely responsible for
> the smooth operation of the network.
>
> If a person at any level above sysop is unable to properly perform their
> duties, the person at the next level may replace them.  For example, if a
> Regional Coordinator fails to perform, the Zone Coordinator can replace him.
>
> To provide for checks and balances at the highest level of FidoNet, there
> are
> two exceptions to this top-down organization.  Zone Coordinators and the
> International Coordinator are selected by a majority vote of the
> coordinators
> at the level below.  Similarly, decisions made by the International
> Coordina-
> tor can be reversed by the Zone Coordinator Council, and decisions made by a
> Zone Coordinator can be reversed by the Regional Coordinators.  See sections
> 6 and 7 for details.  Decisions made by other coordinators are not subject
> to
> reversal by a vote of the lower level, but instead are subject to the appeal
> process described in section 9.5.
>
>
> 1.3  Definitions
>
> 1.3.2  Geography
>
> Each level of FidoNet is geographically contained by the level immediately
> above it.  A given geographic location is covered by one zone and one region
> within that zone, and is either in one network or not in a network.  There
> are never two zones, two regions, or two networks which cover the same
> geographic area.
>
> If a node is in the area of a network, it should be listed in that network,
> not as an independent in the region.  (The primary exception to this is a
> node receiving inordinate amounts of host-routed mail; see section 4.2).
> Network boundaries are based on calling areas as defined by the local
> telephone company.  Even in the case of areas where node density is so great
> that more than one network is needed to serve one local calling area, a geo-
> graphic guideline is used to decide which nodes belong to what network.
> Network membership is based on geographic or other purely technical ratio-
> nale.  It is not based on personal or social factors.
>
> There are cases in which the local calling areas lead to situations where
> logic dictates that a node physically in one FidoNet Region should be
> assigned to another.  In those cases, with the agreement of the Regional
> Coordinators and Zone Coordinator involved, exemptions may be granted.  Such
> exemptions are described in section 5.6.
>
> 1.3.4  Nodelist
>
> The nodelist is a file updated weekly which contains the addresses of all
> recognized FidoNet nodes.  This file is currently made available by the Zone
> Coordinator not later than Zone Mail Hour each Saturday, and is available
> electronically for download or file request at no charge.  To be included in
> the nodelist, a system must meet the requirements defined by this document.
> No other requirements may be imposed.
>
> Partial nodelists (single-zone, for example) may be made available at
> different levels in FidoNet.  The full list as published by the
> International
> Coordinator is regarded as the official FidoNet nodelist, and is used in
> circumstances such as determination of eligibility for voting.  All parts
> that make up the full nodelist are available on each Zone Coordinator's and
> each Regional Coordinator's system.
>
>
> 1.3.5  Excessively Annoying Behavior
>
> There are references throughout this policy to "excessively annoying behav-
> ior", especially in section 9 (Resolution of Disputes).  It is difficult to
> define this term, as it is based upon the judgement of the coordinator
> structure.  Generally speaking, annoying behavior irritates, bothers, or
> causes harm to some other person.  It is not necessary to break a law to be
> annoying.
>
> There is a distinction between excessively annoying behavior and (simply)
> annoying behavior.  For example, there is a learning curve that each new
> sysop must climb, both in the technical issues of how to set up the software
> and the social issues of how to interact with FidoNet.  It is a rare sysop
> who, at some point in this journey, does not manage to annoy others.  Only
> when such behavior persists, after being pointed out to the sysop, does it
> becomes excessively annoying.  This does not imply that it is not possible
> to
> be excessively annoying without repetition (for example, deliberate falsifi-
> cation of mail would likely be excessively annoying on the very first try),
> but simply illustrates that a certain amount of tolerance is extended.
>
> Refer to section 9 and the case studies (section 10.3) for more information.
>
>
> 1.3.6  Commercial Use
>
> FidoNet is an amateur network.  Participants spend their own time and money
> to make it work for the good of all the users.  It is not appropriate for a
> commercial enterprise to take advantage of these volunteer efforts to
> further
> their own business interests.  On the other  hand, FidoNet provides a
> convenient and effective means for companies and users to exchange informa-
> tion, to the mutual benefit of all.
>
> Network Coordinators could be forced to subsidize commercial operations by
> forwarding host-routed netmail, and could even find themselves involved in a
> lawsuit if any guarantee was suggested for mail delivery.   It is therefore
> FidoNet policy that commercial mail is not to be routed.  "Commercial mail"
> includes mail which furthers specific business interests without being of
> benefit to the net as a whole.  Examples include company-internal mail,
> inter-corporate mail, specific product inquiries (price quotes, for in-
> stance), orders and their follow-ups, and  all other subjects specifically
> related to business.
>
>
> 2  Sysop Procedures
>
> 2.1  General
>
> 2.1.1  The Basics
>
> As the sysop of an individual node, you can generally do as you please, as
> long as you observe mail events, are not excessively annoying to other nodes
> in FidoNet, and do not promote or participate in the distribution of pirated
> copyrighted software or other illegal behavior via FidoNet.
>
>
> 2.1.2  Familiarity with Policy
>
> In order to understand the meaning of "excessively annoying", it is
> incumbent
> upon all sysops to occasionally re-read FidoNet policy.  New sysops must
> familiarize themselves with policy before requesting a node number.
>
>
> 2.1.3  Responsible for All Traffic Entering FidoNet Via the Node
>
> The sysop listed in the nodelist entry is responsible for all traffic
> entering FidoNet via that system.  This includes (but is not limited to)
> traffic entered by users, points, and any other networks for which the
> system
> might act as a gateway.  If a sysop allows "outside" messages to enter
> FidoNet via the system, the gateway system must be clearly identified by
> FidoNet node number as the point of origin of that message, and it must act
> as a gateway in the reverse direction.  Should such traffic result in a
> violation of Policy, the sysop must rectify the situation.
>
> =============================================================
>
> There's more at the link above. Read it all to get the "flavor" and intent
> of what a new network could look like.
>
> The future always builds on the past. I believe our experiences of the past
> can
> form the basis for a new paradigm of true autonomy, freedom, and network
> neutrality.
>
> --
> PGP ID: 0x61af18b35c4f9486
>
> _______________________________________________
> discuss mailing list
> discuss AT lists.opennicproject.org
> http://lists.darkdna.net/mailman/listinfo/discuss
>
>



-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive,
Representative & Accountable to the Internet community @large.
----------------------------------------------------------------
  Office: +1 (360) 526-6077 (extension 052)
     Fax: +1 (509) 479-0084

Personal: http://baptista.cynikal.net/