Page tree
Skip to end of metadata
Go to start of metadata


This document advocates for the creation of a distributed curation platform (DCP) on Hyperledger Fabric. It will curate, document, and fairly manage media assets—eg., music, ebooks, photojournalism, gaming figures, digitized artworks, etc on the blockchain. The DCP will accurately establish the provenance of an asset (its past) and assure that the asset’s creators or rights holders are properly acknowledged and remunerated in the future. For this reason, the DCP is suitable for museums, galleries, labels, and publishers on one hand, while proving equally helpful to artists or content creators on the other. In both environments the watchword will remain fairness. The following paragraphs outline a plan to build the DCP in a modular fashion, together with definitions of the relevant and manageable technologies.

The main developer pattern will come from the Hyperledger/IBM Blockchain for Managing Digital Assets, using the IBM Blockchain Platform v2.5 and Hyperledger Fabric 1.4. This section of the introduction borrows directly from the IBM documentation.

The DCP is a digital asset management application, composing and deploying a smart contract on a Hyperledger Fabric Network—which is itself created on the IBM Blockchain Platform. Users interact with this application via a user interface made using VueJS.

Digital Asset Management Systems (DAMS) ensure that operations are only performed on a digital asset by individuals (or organizations) that have the right access rights and permissions for the asset. The digital asset is defined as the content (an image, a music file, a document, a video file, etc.) and its metadata. The metadata could be as simple as the name of the asset, the name of the owner of the asset and the date of creation of the asset, or it could be something more complex, such as extracted speech from a video (subtitles). In any DAMS, there can be any number of users, who in turn may have the ability to perform permission-specific actions. Examples of such actions include:

  1. User registration and user login.
  2. Viewing all existing assets in the system.
  3. Viewing assets owned by the user that is currently logged in.
  4. Uploading a new asset.
  5. Deleting an existing asset.
  6. Suggesting edits to an existing asset.
  7. Viewing suggested edits for an asset that is owned by the user that is currently logged in.
  8. Approving or denying suggeested edits for an asset that is owned by the user that is currently logged in.
  9. Allowing other users the permission to update an asset owned by the user that is currently logged in.
  10. Assigning another user as the owner of an asset that is owned by the user that is currently logged in.
  11. Downloading assets.

The large number of users (participants) in this use case, as well as the different kinds of actions (transactions) executed, indicate a good use case for blockchain.

The DCP will start by packaging the Node.js smart contract using the IBM Blockchain Platform Extension for VS Code. Next, one can create a Hyperledger Fabric Network on IBM Blockchain Platform where ones installs and instantiates the smart contract. An IBM Cloud Object Storage instance is spun up—to retain the digital assets uploaded to the Digital Asset Management application—plus a fake SMTP testing server using to test email notifications sent by the application. Finally, the VueJS web application, making use of the Hyperledger Fabric SDK, can interact with the network.

     1.1 Architecture Flow

  1. The Blockchain Operator sets up the IBM Blockchain Platform service.
  2. The IBM Blockchain Platform service creates a Hyperledger Fabric network on an IBM Cloud Kubernetes Service, and the Blockchain Operator installs and instantiates the smart contract on the network.
  3. The Node.js application server uses the Fabric SDK to interact with the deployed network on IBM Blockchain Platform, IBM Cloud Object Storage instance and the Mailtrap Server (fake SMTP testing server) and creates APIs for a web client.
  4. The Vue.js client uses the Node.js application API to interact with the network.
  5. The User interacts with the Vue.js web interface to interact with the digital asset management application.

      Click to expand 


     1.2 Required Components 

      1.3 Featured Technologies 

  • Hyperledger Fabric v1.4 is a platform for distributed ledger solutions, underpinned by a modular architecture that delivers high degrees of confidentiality, resiliency, flexibility, and scalability.
  • Node.js is an open source, cross-platform JavaScript run-time environment that executes server-side JavaScript code.
  • Vue.js 2.6.10 is an open-source JavaScript framework for building user interfaces and single-page applications.
  • Fabtoken
  • NFT
  • ISCC
  • OCCP
  • vLEI
  • Custom UI and Player (PHP/JS, HTML/CSS)

      1.4 Prerequisites 

        1.5 By Way of Introduction

Early curatorial enterprise on the blockchain was celebrated in 2017 by Consensys’ own Engineer of Societies, Simon de la Rouviere. In his overview of P2P distributed curation markets (DCMs), de la Rouviere quoted Umberto Eco’s equation of curation or list-making with culture itself.

The list is the origin of culture. It’s part of the history of art and literature. What does culture want? To make infinity comprehensible. It also wants to create order — not always, but often. And how, as a human being, does one face infinity? How does one attempt to grasp the incomprehensible? Through lists, through catalogs, through collections in museums and through encyclopedias and dictionaries.

The benefits offered by a blockchain DCP, de la Rouviere claimed, are not only decentralization and related systems of accountability. They also include the “the [cultural] wisdom of a crowd sharing at scale “ and micro-transactions or tokenized payments. Both will be addressed here.

There are certainly lots of existing content aggregation tools, operating with human or artificial intelligence. Given, however, that DCPs rely on both the filtering of information and an attribution of value to those selected assets, AI is (thus far) less likely to to attribute lasting or accurate cultural worth to any resulting list than a known, human entity within a relatively small and permissioned environment. Culture is a profoundly human and abstract activity, revolving around what many blockchain/DCP scholars like to term a ”Schelling (i.e., focal) point” of consideration. Some DCPs that have arisen around such foci are

In all cases, a relatively small and specialized community creates worth in a permissioned or walled environment, within which individuals determine a value-system. We will move along the same lines, following a brief introduction into existing overlaps between Hyperledger and curated, value-making blockchains. 


Hyperledger’s ​vision statement​ of 2018 highlighted multiple aspects of rights attribution. The in-house HLF project name-checked most often was Dot Blockchain Media (dotBC), a music content rights registry and transaction processor across a then-purported network of more than 63 million compositions. (doTB has since morphed into ​Verifi Media​ and ​Cardstack​, where permissioned blockchains are now combined with the versioning tools of GitHub to create “gitchains.”)

Boston’s ​Open Music Initiative​ ​was also referenced in early Hyperledger materials. Housed in the Berkelee College of Music, the OMI continues today to leverage HLF as a non-profit network of “leading academic institutions, music and media industry organizations, creators, technologists, entrepreneurs and policy experts.” They, like dotBC, worked towards an open-source protocol for the uniform identification of music rights holders and creators.

These efforts were then celebrated by ​Irving Wladawsky-Berger​, former VP of Technical Strategy and Innovation at IBM. Here, simultaneous with HL’s 2018 mission statement, Berklee’s spinoff ​Institute for Creative Entrepreneurship​ (ICE) was singled out for praise, along with MIT’s ​Media Lab​, ​IDEO​ ​and Context Labs​. At this time the ICE already boasted over 200 ​members​ including Sony, Universal, and Warner, together with Spotify, Pandora, Netflix, SiriusXM, YouTube, and Alibaba.

Quoting an ​article​ in Wired, Wladawsky-Berger hoped to use blockchains or decentralized databases to bridge the “serious information gap... or disconnect between the person who composed a song, the person who recorded it, and the subsequent plays... No-one owns the information, but everyone can access it... Keeping track of this metadata [will mean] artists and platforms can leverage it various ways without fear of violating rights.” Hence the OMI’s ​Minimum Viable Interoperability​ APIs (MVI 1.0), syncing data associated with recordings, musical works, creators and right holders.

And so, with most frequent reference to ​Sawtooth​ (made publicly available in early 2018), HL was looking to “replace monolithic central systems with an approach based on interoperability among existing databases and distributed transactions.” Parallels were drawn with the Ethereum blockchains of Canada’s ​CoreRights​ or Consensys’ ​Ujo Music,​ who worked on smart contracts with London singer/songwriter Imogen Heap and her blockchain advocacy group ​Mycelia​.

In this same spirit of curatorial inclusion, value-creation, and proper attribution, it is therefore proposed that the ME-SIG embody the inclusive 2020 vision of Ashna Gupta​. Her example of music is translatable to other digitized narratives, be they e-books, photojournalism, e-games, or movies.

Imagine this: a single platform where you can search for a song and uncover a record of every single player that has touched that song from inception to delivery. Every songwriter, producer, sound engineer, and everyone in between. Imagine a transparent revenue-sharing model that pays artists their fair share of royalties right away. Imagine a world of increased trustand accountability between artists and large media corporations.

There have been some moves in this general direction at IBM, where supply chain models could become the groundwork for entertainment platforms. Unfortunately, none of these sketched plans (often with the engineering of Horea Portuiu) are afforded long-term support by IBM. They could (indeed, should) be worked up into a media delivery platform that might:

  • help to combat piracy
  • assure the provenance of media assets
  • bypass rapacious middlemen
  • lay the groundwork for a system of digital collectibles using NFTs
  • and foster creative or journalistic local scenes.

2.1 HL Rights Management for Older or “Heritage” Assets. The Museum Network.

In building a test-case or POC, this DCP project will employ a large, existing audio database: a collection of approximately two million audio files that span the history of recorded sound in Russia. These files have recently been recently donated to the Wende Museum of the Cold War in Los Angeles (Instagram / Museum Review). What they require, over and above any issues of metadata, provenance, or rights management, is a public-facing API or decentralized streaming system of direct benefit to other archives, galleries, and publishers internationally. This use-case we will henceforth refer to as MN (“museum network”).

The physical collection from which the test files were partially generated can be seen here: these vinyl recordings, tapes, flash drives, mini-discs, traditional CDs, etc., will help the ME-SIG to define best practices for placing tangible, often antique objects on the blockchain.

The MN will be built with two primary emphases in mind:

  • Digital lending with ISCCs (see below)
  • Decentralized curation and records management

2.2 HL Rights Management for Contemporary and Future Assets. The Contemporary or Commercial Network.

In addition, MN will grow parallel to a more contemporary or commercial alternative, designed to help the work of living artists alive today from the same eleven time zones. The API or UI for this network (henceforth “CN”) will focus upon the following issues:

  • Easier access to (and the improved exchange) of better metadata
  • Compensation for the composers of audio works using ISCCs*
  • Support for the micro-sale of sync licenses across social media. (How might an individual or company legitimately license and share the work of a major artist, say, on social media?)
  • Support for the tokenization of audio with Hyperledger’s Fabcoin and/or NFTs**
  • Support for healthier competition in the subscription market. (How might an individual launch a subscription service for my customers/audience and easily access proper licenses?)
  • and a geo-sensitive/hyper-localized news service. News of cultural or political worth will be embedded in a map, showing (in cultural cases) the geographic origin of a file and (in journalistic cases) verifiably true statements about both local events and regional politics. As a result, CN will aid freedom of speech and freedom of expression in territories where both are rare. Evidence of background work is gathered here.

It is hoped that one API or app will suffice for both MN and CN, with either different interfaces and/or functionality to meet divergent needs. Those divergences might include the expression of rights (i.e., rights-expression languages or REL) and matters of post-transaction fulfillment (DRM, access control). Alternatively, those same functions—for example the presence or absence of payment details—could be embedded into the files themselves, thus largely eliminating the need to separate or isolate a museum collection from a contemporary or commercial equivalent. One app, two forms of access: archival or commercial. Non- or for-profit, filtered by the app’s search engine. 


3.1 Tokenization: Fabtoken

Since HLF2.0, token-creation follows a system of decentralized chaincode management. FabTokens can now be transferred, exchanged or redeemed between users. Tokens are issued by owners to other members of the channel willing to purchase. Both token issuers and peers need to possess authentic MSP identifiers in order to process tokenization. Tokens are stored on the blockchain ledger that endorses immutability and security, thus making the token itself immutable—which means it cannot be issued or transferred without owner consent.

These tokens are linked to a DCM’s value-making as follows:

In terms of token generation, tokens are minted continuously according to a price initially set by the smart contract. (The price of this token actually becomes more expensive the more tokens are in circulation, as it becomes more expensive to buy into the community the more popular it becomes.) The total sum paid for the tokens is kept in a communal deposit. At any time, participants can withdraw their token from the active supply, effectively “burning” it, in exchange for a proportional sum of the communal deposit, which would be denominated in the form of another coin, perhaps.

3.2 HLF and NFTs

Hyperledger’s primary connection with NFTs remains the 2019 study conducted at Cornell by Mustafa Bal and Caitlin Ner: “NFTracer: A Non-Fungible Token Tracking Proof-of-Concept Using Hyperledger Fabric.” The study - and resulting repo - are introduced thus, with the confidentially fitting real-world example of an art auction.

Various start-up developers and academic researchers have investigated the usage of blockchain as a data storage medium due to the advantages offered by its tamper-proof and decentralized nature. However, there have not been many attempts to provide a standard platform for virtually storing the states of unique tangible entities and their subsequent modifications. In this paper, we propose NFTracer, a non-fungible token tracking proof-of-concept based on Hyperledger Composer and Hyperledger Fabric Blockchain. To achieve the capabilities of our platform, we use NFTracer to build an artwork auction and a real estate auction, which vary in technical complexity and demonstrate the advantages of being able to track entities and their resulting modifications in a decentralized manner. We also present its accompanying modular architecture and system components, and discuss possible future works on NFTracer. 

An intriguing an equivalent concept was published by Consensys (“Bootleg”) a couple of years ago, but was never fleshed out. Fragments of Verifi.Media’s Sawtooth platform are accessible on GitHub.

3.3 HLF and the Possible Extension of Existing Supply Chains

Over and above the HL Blockchain for Maintaining Digital Assets noted above, elements of prior blockchain softwares could also be employed to augment that core architecture. 

Several IBM engineers, most notably Horea Portuiu, have used Hyperledger over the last two or three years to hypothesize how existing supply chains could serve as the backbone for a music-centric DCP. Some of the most promising are, unfortunately deprecated and/or no longer managed.

  • Fabric Contract Attribute-Based Access Control (no longer maintained). Demonstrates the implementation of attribute-based access in HLF supply-chains; IBM Blockchain Platform VSCode.
  • Blockchain Bean (no longer maintained/archived). Increases visibility and efficiency in the supply chain of a coffee retailer.
  • Tuna Supply Chain (archived / detailed walkthrough): “The fisherman [is called] Sarah. After each catch, Sarah records information about each individual tuna, including: a unique ID number, the location and time of the catch, its weight, the vessel type, and who caught the fish. For the sake of simplicity, we will stick with these six data attributes. However, in an actual application, many more details would be recorded, from toxicology, to other physical characteristics.”

         One or more of these could theoretically be retooled. 


The rightsholder (Wende Museum) could generate ISCC from the digital assets, register ISCC on the blockchain, and then associate metadata and licensing terms to the ISCC on the blockchain. The assets can be tokenized as fungible or non-fungible tokens.

4.1 Generation of ISCCs

Some basic information about the International Standard Content Code (ISCC):

  • An ISCC is derived from the digital content itself; it can be generated by anyone with access to the relevant media asset(s). The ISCC helps to identify digital assets or similar versions thereof in different formats in across decentralized environments. In other words, an ISCC can be generated from an asset without any previous exchange of information, access to metadata, or coordination of file-name conventions

  • The ISCC has been accepted as a PWI at ISO TC 46/SC 9/WG 18 "NP 24138 – International Standard Content Code".

  • Specifications ( and all open-source development ( are maintained by the Dutch nonprofit ISCC Foundation. This ensures interoperability and the transparency of digital content identification.

The advantages of the ISCC over cryptographic hashes in identifying assets may be listed as follows: 

  • Even if an asset has been modified, compressed or converted into a different file format, the content can still be identified. The ISCC uses fingerprinting technology for advanced and automated content identification, content clustering (content-variant detection, related product identification), and content versioning. This is not possible with a cryptographic hash (e.g., SHA 256). It is worth noting, however, that the ISCC cannot be compared to automated content recognition technology (ACR systems).

  • The ISCC is a universal standard identifier for digital content files in all formats (text, image, audio, video) and a newly proposed cross-industry standard for all media sectors.

  • An unlimited number of ISCC can be generated free of charge. There is no need for a centralized registration authority, providing identifiers to rights-holders. As the ISCC is generated from the asset itself, identifiers do not need to be manually assigned.

4.2 Registration of ISCCs

(Possible Illustration: Rightsholder —> ISCC)

One way to connect a rights-holder to the ISCC is through registration of the ISCC on a public blockchain network (TBD).

In order to be used on the Museum Network (MN) and the Contemporary Network (CN), the ISCC—as the representation of an asset—can be registered on a blockchain that is permissioned (for input data or transactions) but is also partially public. Customer services, shops, retailers, and decentralized application (aka DAPPs) may then have access to identifiers and other information on the chain.

By using wallet software (or other methods) to sign an ISCC registration transaction on the DCP, an actor is verifiably and inseparably given control of the private/public keypair. The same actor could use DID/SSI (with verifiable credentials (VC)) to sign (to be discussed).

Furthermore, an ISCC could also be a DID (to be discussed).

4.3 Generation of NTFs

(Possible Illustration: Actor —> ISCC —> Metadata/RMI —> NFT)

If required, NFT can be generated to be used on the Hyperledger-based distributed curation platform (DCP) or Ethereum-based networks and platforms. By using the ISCC, interoperability is ensured.


5.1 Association of metadata and rights management information to ISCC

(Possible Illustration: Actor —> ISCC —> Metadata/RMI)

Having registered the ISCC by signing an initial ISCC registration transaction, the same rights-holder can now associate metadata and rights management information with that ISCC. One possible way of doing so would be with verifiable credentials (to be discussed).

Alternatively, a rights-holder uses the same wallet software (i.e., a public/private keypair) both for associating rights management information with the ISCC and registering it. This way, the ISCC and its metadata/rights management can be verifiably tied to one and the same person. With his/her keypair, a rights-holder can technically prove that any subsequent messages or metadata updates associated with this ISCC are coming from the same credentials (to be discussed).

5.2 Content certification

(Possible Illustration: Actor —> ISCC —> Metadata/RMI —> NFT —> Verifiable Identity)

Applications and users of the Museum Network (MN) and the Commercial Network (CN) need to trust the information associated with an ISCC. They need to verify in a decentralized manner (without the use of centralized services) that the metadata and rights information associated with an ISCC come from a trusted actor.

This trust can be established by DIDs/SSIs and verifiable credentials (to be discussed).

An alternative is suggested by the Open Content Certification Protocol (OCCP), Entities that serve as certification authorities could use vLEI (verifiably legal entity identifiers) to prove their authority to issue verifiable credentials or create trust in content certificates. (to be discussed)

5.3 Verification and access to metadata and rights management information

If a third party curator and possible licensee wants to make use of an individual choice of content from the rightsholder collection, he can identify the assets by their ISCCs, locate metadata and rights management information and verify that both has been provided by the legitimate rightsholder.

5.4 Examples for content licenses

If a licensor has granted the use of content for the specific use case, a licensing transaction can be triggered in various ways:

a) the licensee could acquire a defined number of streams/loans. In this case the number of streams/loans could be tracked by a media player or otherwise defined,
b) the licensee could acquire a right to stream for a defined period of time. Access to the content could be granted by an application that checks verifiable credentials (VC) which have been issued by the rightsholder and licensor to the licensee after the licensing transaction,
c) content could be provided for research purposes according to the general academic standards.

5.4 Metadata standards and rights expression languages

The rightsholder should be able to associate metadata and rights management data in such a format that suits best his content and matches best the expectations of his intented users, customers, platforms and licensee's.

Metadata and rights management data should be expressed in a machine readable and human readable format as a 'ricardian contract' so that they can be read by parties involved and transactions can be executed automatically.

"A Ricardian contract places the defining elements of a legal agreement in a format that can be expressed and executed in software. The key is to make the format both machine-readable, such that they can easily be extracted for computational purposes, and readable as an ordinary text document such that lawyers and contracting parties may read the essentials of the contract conveniently." (

Potentially interesting projects:

REL's – Rights Expression Languages for Music


This project will distribute more revenue to artists such that automated micropayments bypass intermediary agents and foster independent, decentralized broadcasting and rights collection networks. These take the form of DAOs and DACs: decentralized autonomous organizations/companies.

DAOs involve a set of people interacting with each other according to a self-enforcing open-source protocol. Keeping the network safe and performing other network tasks is rewarded with the native network tokens. Blockchains and smart contracts hereby reduce transaction costs of management at higher levels of transparency, aligning the interests of all stakeholders by the consensus rules tied to the native token. Individual behaviour is incentivized with a token to collectively contribute to a common goal. Members of a DAO are not bound together by a legal entity, nor have they entered into any formal legal contracts.21 Instead, they are steered by incentives tied to the network tokens, and fully transparent rules that are written into the piece of so ware, which is enforced by machine consensus. There are no bilateral agreements. There is only one governing law – the protocol or smart contract – regulating the behavior of all network participants.

This collaborative HL project is dedicated to the involvement of more users with increasingly valued assets, who in turn will encounter lower barriers to increased involvement—and so forth. These cyclical processes of increasing worth are what underlie the recent upsurge in curation markets—the ability of peripheral entities and their “minor” assets to create independent value-systems away from centralized enterprise.


The issue of HL’s inherent complexity or difficulty - i.e., of obstacles to diversity and inclusion - leads some journalists to declare that Fabric is “far more complex than any blockchain platform.” The original proposal for the Hyperledger ME-SIG sketched the involvement of HL(F) in media and/or entertainment initiatives across two periods in recent history:

  • the initial forays of 2017-18
  • and the more current events of 2020-21.

The same text proposed, at least implicitly, that two barriers have impeded the uptake of DLT and permissioned blockchains by the general public since 2017. The inclusive ethos of HL as open-source technology can be hard to promote, either because

  • it becomes part of proprietary backend engineering or because
  • HL itself involves a steep learning curve for average coders (in both senses of that adjective). For example: “When I was learning Hyperledger Fabric for the very first time, I found that it was difficult to understand how Hyperledger Fabric really works because of its enormous technology stack. To really understand how it works, a learner is required to have knowledge of several aspects such as blockchain technology, network and system architecture, DevOps operations, full-stack software development, test driven and behavior driven development, intermediate-level cryptography, authorization and access control, IT security aspects, business use cases, etc.”

This project must emphasize ease-of-use.

7.1 Metadata and Search

The proposed test-materials are in many languages: English, French, German, Russian, Ukrainian, Belarusian, Estonian, Latvian, and Lithuanian-to name but nine. This makes the database very suitable for language- and character-specific search experiments, not to mention earlier problems of find and embedding metadata. Thus far, the greatest success—with metadata and duplicates—has been with the UK software, SongKong. This program relies not only on Western, mainstream attribution databases, but also on locations such as Discogs, where less familiar genres and recordings are more likely to be documented.

That textual information, together with tools like Beatunes (from Fraunhofer Labs, the home of the MP3) allow for non-linguistic search terms to be added. Once the audio files have undergone these British and German checks, a DB can look as below. Over and above generic tags such as Artist, Song, Album, Year, Genre, etc., other factors come into play. They may all be  automatically read against one another and form metadata to aid public searchability. 

  • Bpm (beats per minute) 
  • Key (calculated from 30-second samples) 
  • Transitions (depicted visually) 
  • Language (detected from lyrics, the audio itself, track titles, or cover art) 
  • Lyrics  
  • Mood (algorithmically calculated––albeit sometimes with mistakes! Based on quantifiable vectors of happiness [+/-] and relative arousal) 
  • Color (a chromatically-coded comparison of tracks. “Yellow” tracks, for example, share  formal characteristics with other yellow compositions––in that playlist, on that day.

Quite what those characteristics are remains unclear until the colored tracks are placed side by side. Points of comparison are algorithmically suggested, yet comprehended/interpreted  by the human subject. This generates special playlists that change each time the audio library’s contents are  altered. New data = new contexts = new comparative linkages.


7.2 UI Wireframes

The same color-coding, when transferred to an UI sketch, produces the following design possibility. In this instance, the needless complexities of multilingual/multi-script search are replaced with a color-coded mood search. And, in turn, that search is connected to the geographic specificities of a post: where a performer happens to be - or where they are performing. From a journalist’s point of view, the app would use geolocation for different purposes, connected more to freedom of speech. 

In Russia, underground compositions are the sine qua non of free speech. They are the foundation of social liberty. Independent sounds and voices are priceless in a country that Reporters Without Borders ranks 149th in a descending list of 180 nations worldwide: “What with draconian laws and website blocking, the pressure on independent media has grown steadily… Murders and physical attacks against journalists continue to go unpunished.” Independent voices emerge, are harassed, and then vanish. Put simply, artists––given a superior alternative––can be taught how to run it themselves, together with all the requisite, reliable connections to law-abiding US organizations.   

The CN platform (alternative UI design below) allows people to access the news stories closest to them – again on handhelds and tablets.

The Russian/ Ukrainian newspaper business has been decimated by the web; simultaneously, Russian centralized media allows no room for democratic debate. The CN, however, lets people attach texts, audio, or video to specific coordinates. For example, a political story is fixed – on that same map – to the location where events are unfolding. As people move through a city or village, they define a radius of interest (say, three miles) and receive all the citizen news within that catchment area. They can also filter stories depending on a topic of interest, even creating new hashtags of their own. This means that the content of a “local newspaper” changes constantly as one drives across the landscape -­‐ or walks around town. Isolated voices come together as a community service to counter or complement official opinion. The technology used to gather citizen information can also be used to find and nurture local writers -­‐ or musicians. The CN will, for example, create a stream of the nearest musicians, whose work is also embedded in the map. Free speech becomes audible, visible, and endlessly relevant. 


As for CN, a UI already exists, linked to a CouchDB instance and designed to both stream locally specific audio and showcase the work of individual artists. Ease of use has been the guiding principle. Those designs can be viewed here; the player (see below, final slide) is built with JavaScript, PHP, HTML and MySQL, resembling a Spotify app in functionality. The challenge lies in merging these multiple foundational ties in one very simple interface that museums, publishers, performers, and audiences can all use with ease.


*  Companies such as Digimarc discuss such options in their report, “Watermarking Technology and Blockchains in the Music Industry.” “A player app could read the watermark and deposit a transaction on a blockchain in real time, and/or the watermarks could be detected and matched to transactions on the blockchain as part of a periodic auditing process. This is analogous to sampling schemes that certain PROs use to determine music played on broadcast radio for royalty distribution purposes. Some of these schemes use fingerprinting [see p13 of the report]; watermarks would be more accurate and flexible.” Such processes have long been advocated by Mycelia for Music in the UK.

**  A network of unique/traceable collectibles can be established with NFTs, following the guidelines at OpenSea. By way of one example, there is some precedent for musical NFTs being auctioned on the decentralized protocol

  • No labels