Art By City started primarily as an artist-focused DApp (https://artby.city) during the Open Web Foundry in Q4 2021. As our focus is on utilizing a decentralized web to empower creators through discoverability and curation, we quickly realized the need to categorize different types of creative asset publications, their intended rendering containers, metadata, licensing, and associated meta-actions such as liking, tipping, or sharing. We began outlining a specification to be implemented as tags on Arweave transactions so that our own dapp could discover these assets, know how to render them properly, display the associated creator metadata (e.g. title, description, license), and begin building a curation graph we could crawl later through likes and tips. This work was designed while the DApp was being developed by necessity and through code.
We continued to refine the spec, through code and many conversations - we've spoken to dozens upon dozens of Arweave projects, founders, VCs, artists, and developers about the Art By City Protocol spec. We realized we needed to write it all down so in April 2022 we authored the majority of the Art By City Protocol Whitepaper. This whitepaper outlines more than the Art By City Protocol specification, such as a supporting Profit-Sharing Network and DAO, but are beyond the scope of this post and discussion.
We recently became aware of ANS-110 and are very interested in merging / contributing based on the work we've done so far for the Art By Cith Protocol spec.
The below section is a brief summary of the specification outlined in the Protocol section of the Art By City Whitepaper (please feel free to reach out for commentor access): https://docs.google.com/document/d/1-sp6J4z8nGP7DnBjW_ucU5IO9bZWt1kTz_YrCtNHVhU/edit?usp=sharing
Briefly put, publications coming from the Art By City DApp are ANS-104 bundles purposely built to atomically represent a logical creative work. Included in the bundle are original assets, preview assets such as thumbnails or streamable audio, metadata, and manifest information. It is not necessary that creative assets participating the Art By City Protocol spec are published in this format.
These tags outline the intention to participate in the spec and a category the transaction is meant to represent.
| Tag | Optional? | Value | ANS-110 Equivalent (tag:value) |
|---|---|---|---|
| Protocol | False | ArtByCity |
Implements: ANS-110 |
| Category | False | One of (Artwork or Publication), Avatar, (Profile or Bio), Like, Tip, Curation, Boost depending on the type of transaction. |
N/A |
Additional tags depend on the specified Category.
Artwork was the original category used. We have since begun to transition to the use of Publication to be more generic but either are equivalent. More Sub-Categories would be added should the need arise: e.g. code, theme, component
| Tag | Optional? | Value | ANS-110 Equivalent (tag:value) |
|---|---|---|---|
| Sub-Category | False | One of: image, audio, video, model, text |
Type: image, video, etc. |
| City | True | Somewhat deprecated, 3 letter city code of the creator's choice for discoverability. | N/A |
| Medium | True | Free-form creator's choice for discoverability | N/A |
| Slug | True | Human-friendly URL slug, specified by the creator, serving as a unique identifier for the publication. | N/A |
Like and Tip are distinct in that likes can happen once and are intended to be for some kind of associated publication where the creator receives any attached tip amount. Tips are meant to be direct to the user and can happen more than once.
| Tag | Optional? | Value | ANS-110 Equivalent (tag:value) |
|---|---|---|---|
| Liked-Entity | False (for Like) |
Transaction ID of liked publication (Category: Artwork or Publication) |
N/A |
| Sub-Category | True | Platform-specific, e.g. DeSo Diamond |
N/A |
Curation plays a critical role in discoverability. This Category is meant to be used for a list of creative works previously published with this spec. We've developed a series of SmartWeave Curation Contracts for this purpose but they have not yet been tested for a production release.
| Tag | Optional? | Value | ANS-110 Equivalent (tag:value) |
|---|---|---|---|
| Sub-Category | True | e.g. Playlist, Album, Mixtape, Collection, Series |
N/A |
In order to aid cross-chain, cross-platform rendering of creative assets being published to Arweave, developers could specify a reference identifier to a JSON metadata/manifest file format that represents a publication.
| Tag | Optional? | Value | ANS-110 Equivalent (tag:value) |
|---|---|---|---|
| Manifest-Format | True | Platform, chain, ecosystem specific ArtByCity, SolanaMetaplex, EIP-721 |
N/A |
Sometimes creators publish things and wish to retroactively participate in the spec.
| Tag | Optional? | Value | ANS-110 Equivalent (tag:value) |
|---|---|---|---|
| Original | True | Transaction ID of original publication, owned by this transaction's owner | N/A |
Often, creators wish to republish their work with an updated or corrected version. Similarly, as outlined above, Slug can be used as an overall unique identifier of a logical creative work.
| Tag | Optional? | Value | ANS-110 Equivalent (tag:value) |
|---|---|---|---|
| Edition | True | Creator's choice of versioning system, e.g. semantic (1.0.0) |
N/A |
| Edition-Of | True | Transaction ID of original publication, owned by this transaction's owner | N/A |
Sometimes, creators wish to publish royalty intentions with their work.
| Tag | Optional? | Value | ANS-110 Equivalent (tag:value) |
|---|---|---|---|
| Royalties | True | Transaction ID of a Royalty Intentions document, similar in function to ANS-105 | N/A |
The Art By City Protocol is intended to be used in combination with existing ANS specs such as ANS-105 for licensing, or ANS-108 for cross-blockchain creator ownership discoverability.