Hypermush

Hypermush
Name	hypermush
Location	De Bonte Zwaan
Date	2018/07/27
Time	10:00-17:00
PeopleOrganisations	André Fincato, Marcel Goethals
Type	HDSA2018
Web	Yes
Print	No

hypermush was a workshop that introduced p2p technologies and their user-applications when disguised as a multi-user-shared-hallucination (MUSH) videogame.

MUSH’s are an evolution of MUD (multi-user-dungeon) which are early multiplayer text-based adventure videogames from the 1970s. We used the MUSH game dynamics to explore the p2p dat protocol protocol, and build shared and interconnected narratives by way of dungeon explorations, user group formation, file tradings and key discovery, until it got hyperreal…

Following the slides used during the workshop, and adapted as loose notes to give an introduction to the workshop themes.

http vs p2p

http

Simple functioning of an http(s) server

       (→ hi!)

client =========> server

        (cats, death, rabbit hole, etc ←)

client <========= server

p2p

What is the difference between http(s) and p2p?

• http → you visit locations that serve files (e.g. you visit the url of a page and that page spits back the content [= files] contained in that page).
• p2p → you visit files directly.

• http imposes (and needs) a server/client architecture, e.g. some computers dispense information, others can consume that information when going to the right location.
• p2p turns any computer into a node of the network:
  • you can just simply connect with other computers (publish and share stuff, work on the same files, broadcasting, etc.)
  • you are using your own computation power instead of using dedicated computers acting as servers.

• http you upload your data onto a server (encryption on? secure connection?).
• p2p by default stores your data onto your device, fully encrypted (e.g. dat).

→ p2p makes a good alternative to most silicon-valley applications

LAN vs Blockchain

RAND Corporation, a nonprofit think tank working for the United States Air Force, asks the question: would the USA's communications infrastructure withstand a nuclear assault?

Why not have a small, decentralised, distributed nodes model, rather than always having a planetary synchronised ledger (aka blockchain)?

MUSH

Rules in order to take part in the hypermush dungeon game.

intro

• what is a mud → multi-user dungeon
• what is a mush → multi-user shared hallucination

design

• character design
• dungeon design

hypermush

• install hypermush, and use it to chat (clan organisation, single efforts, etc.)
• grab it from the usb stick
• or download the repo
• use dat, either through the command line or beaker, to exchange, trade and share files.

hypermush commands

• connect to a host using `/join key`
• set your name using `/name yourname`
• go to a room using `/go to roomname`
• you can describe what you're doing using `*eats a banana*`
• host a new session using `/host conversationname`

dat cli commands

• create dat, import files and share dat share
• create empty dat dat create
• make a copy of a dat dat clone
• sync files to existing dat dat sync

During the mush, people built their own dungeon in the form of a dat website, eg making a simple html page hosted directly on their laptop through dat, and accessible in the Local Area Network for anyone to visit, by way of the website address.

In the case of dat websites, you don’t have a typical url (eg www.dungeon.net), but a 64 long character string, called hash, eg dat://073d0091b1f8231facae13241ecebab8fa808f6f715e857fcd394dfc0cf4dad8

Because of this, discovering and accessing dungeons was not that immediate, simply given the nature of the long address you had to retrieve. Furthermore, playing with the connotation of this hash being the key to your dungeon — which in the p2p context this hash is actually called public key — participants would come up with different realities for their dungeons, and different reason to connect to other dungeons, in the form of embedding in their website the key to another dungeon.

These technical and aesthetic elements enriched the make-your-own-dungeon experience, and participants began to connect several html pages together in a labyrinth form, hiding the key to other dungeons in elaborate ways (design camouflage, riddles, multiple choice buttons that would bring you to other sub-pages, etc).

The more dungeons you would get access to, the more you could expand your map of dungeons as well as being able to re-host (make available) those dungeons yourself through your computer.

In the end, you had to come up with ways to convince other users to trade their keys to you and vice-versa, while keep exploring the LAN until you’d find more dungeons to connect with, or ignore. Part of the fun to re-host someone else’s dungeon was that you could change their design and structure, in so doing create a new hash / public key for it, and keep expanding in hallucinatory ways the landscape of the game. Most probably nobody reached a point where they had a total overview of it all.

Glossary

A few relevant keywords from the glossary of bittorent terms, to adopt and adjust based on the p2p protocol at hand:

• hash: ‘hash’ is the shorter form of the word ‘hashsum’, and it refers to the string of alphanumeric characters (typically hexadecimal) in the .torrent file that the client uses to verify the data that is being transferred.
• distributed hash table: a distributed hash table (dht) is a class of a decentralized distributed system that provides a lookup service similar to a hash table; (key, value) pairs are stored in a dht, and any participating node can efficiently retrieve the value associated with a given key. Responsibility for maintaining the mapping from keys to values is distributed among the nodes, in such a way that a change in the set of participants causes a minimal amount of disruption. This allows a dht to scale to extremely large numbers of nodes and to handle continual node arrivals, departures, and failures.
• peer: a peer is one instance of a bittorrent client running on a computer on the internet to which other clients connect and transfer data. Depending on the context, ‘peer’ can refer either to any client in the swarm or more specifically to a downloader, a client that has only parts of the file.
• seed: a seed refers to a machine possessing some part of the data. A peer or a downloader becomes a seed when it starts uploading the already downloaded content for other peers to download from. When a downloader starts uploading content, the peer becomes a seed. ‘Seeding’ refers to leaving a peer's bittorrent client open and available for additional individuals to download from.
• leech: a leech simply describes any peer or client that does not have 100% of the data. But it also refers to a peer (or peers) that have a negative effect on the swarm by having a very poor share ratio by downloading much more than they upload. Leeches may be on asymmetric internet connections or do not leave their bittorrent client open to seed the file after their download has completed. However, some leeches intentionally avoid uploading by using modified clients or excessively limiting their upload speed.
• lurker: a lurker is a user that only downloads files from the group but does not add new content. It does not necessarily mean that the lurker will not seed. Not to be confused with a leecher.
• swarm: a swarm refers to all the peers that share a torrent. This is a holdover from the predecessor to bittorrent—a program called swarmcast—originally from opencola.

References:

Resources

• p2pforever.org
• peer-to-peer-web
• distributed web of care

Protocols

• dat
• ipfs
• scuttlebutt
• zeronet
• activity pub
• bitcoin
• the whole blockchain scene
• bittorent

and others... (p2p is in abundance)

• 
• 
• 
• 

Published in Fake it! Fake them! Fake you! Fake us! Publication in 2019