API / alternative distribution methods

[ismay]

I was thinking of creating an adblocker that replaced ads with art, and was happy to see that it already exists 😊. I saw that you're using json to define exhibitions, and allow people to define their own exhibitions, etc.

That got me thinking. I was wondering if you'd be interested in distributing those exhibitions through other channels than add-art. Personally I think that that has a lot of potential, as exhibitions could be shown on photo frames, dedicated monitors in homes, galleries, etc. Say for example that through an api people could get a list of all exhibitions, or an exhibition by id, etc.

What I'm looking for in the end is an less platform-dependent way of distributing modern art. Currently there aren't a lot of good independent online distribution channels for art in my opinion, or they're fragmented and hard to discover. There are some communities, but in my opinion most are very commercial and not that interesting to me as an artist. I'd like to be able to follow a curator that I like, or an artist that I like, etc.

I just saw what you created and was wondering whether this (at the moment admittedly still broad) direction fits with the add-art project.

[owise1]

Hi,

Sorry for the delay. I've been away on vacation. Yes, what you're talking about does fit with this project in a way. As you mentioned, the exhibitions are just json files, and you can add you own exhibition simply by adding a URL that returns an json file. In fact, here is the repo containing the "default" add-art exhibitions: https://github.com/owise1/addendum-exhibitions/blob/master/exhibitions.json

I'm also interested in a "less platform-dependent way of distributing modern art". A long time ago, my partner and I made an online gallery for digital artwork (http://artmicropatronage.org/exhibitions). Those exhibitions are no longer public, however that platform was built using the same idea. Each work was it's own public json file and all our platform did was "render" it. Each piece was essentially meta data. So it was just about trying to figure out how to structure the json in a flexible enough way to meet all of the artists' requirements. I think that is the crux of what these projects were after, defining an open specification for artwork online.

anyway I'm happy to chat about this more. we'd be totally down to distribute the exhibitions somewhere else. The exhibitions that user's create here: https://add-art.org/essays/ are stored in a public couchdb, so all of that info is technically public already. There's just no good way to search it right now.

[ismay]

No problem, thanks for the reply!

I think that is the crux of what these projects were after, defining an open specification for artwork online.

I think it's a nice specification, seems like it would fit most work.

The exhibitions that user's create here: https://add-art.org/essays/ are stored in a public couchdb, so all of that info is technically public already. There's just no good way to search it right now.

That's nice. So we could theoretically build a REST api on top of that?

The problem

I think maybe it'd be good to brainstorm a bit about what the problem is we're trying to solve, for who, what kind of solutions we'd prefer, etc.? Personally, this is the problem I'd like to solve:

• A lot of modern art is difficult to find. It is either drowned out by a couple of best-sellers on the art-platforms out there. Or it is on a personal portfolio that is difficult to discover.

• The same problem from the perspective of the artist: it is difficult to get noticed online. It seems there are some that get a lot of attention, but most seem to not get noticed at all, on either platforms or their personal websites.

To start

So let's say we extend the add-art essay tool a bit. We could build a read-only rest api that allows you to retrieve exhibitions, artists, work, etc.

It seems like that could allow others to build things like an app for curators to curate their own exhibitions, a portfolio, or even display random exhibitions on a monitor, etc.

A couple of problems I'm thinking about (and I'm probably missing a lot since I'm not a backender):

• Outdated images/exhibitions. Since we're not hosting the content, but just metadata, how do we handle content that is no longer available?
• Speed/scalability. I wonder if this all would be scalable. If people start using it to build their portfolio for example, all visitors would be retrieving content through our api. And we wouldn't want it to get slow. So we either need a free service that we could use, or money from somewhere.

Besides that, building an api to retrieve art with is nice, but it would have to be used by artists, and people would have to build stuff with it. I wonder if that is something that would happen. I'm just brainstorming here, and I might be looking in the wrong direction, so I'm curious what you think!

[owise1]

That's nice. So we could theoretically build a REST api on top of that?

A couchdb is actually all based on REST. You use POST and PUT to add things to the db and GET to retrieve things. The only complication would be managing permissions: who is allowed to add to the artwork database? You could make a small wrapper around the database to enforce whatever scheme we came up with for verifying people. But that's an important question, who should be able to add works and how would you protect against spamming the system?

Since we're not hosting the content, but just metadata, how do we handle content that is no longer available

Technically you can store assets along side the meta data document in the db. So in theory each document could be self contained. For example, I believe the npm registry is built on couchdb and they store the zip files of each module along with it's meta data.

....Or it is on a personal portfolio that is difficult to discover.

Maybe you make a Wordpress or Indexhibit plugin for artists who use those platforms for their personal site to help them export their artworks in the proper format to the giant art database

Honestly the way I've always imagined it is a giant, open, messy database filled with everything. And then a bunch of other scripts organizing it and consuming it in different ways. I'm not sure this solves your particular issue though, but it might be a way to design the architecture underneath it.

[ismay]

The only complication would be managing permissions: who is allowed to add to the artwork database? You could make a small wrapper around the database to enforce whatever scheme we came up with for verifying people. But that's an important question, who should be able to add works and how would you protect against spamming the system?

Yeah, that definitely seems tricky. Especially if you want it to be open. Seems like maybe it would need moderation at some point.

Technically you can store assets along side the meta data document in the db. So in theory each document could be self contained. For example, I believe the npm registry is built on couchdb and they store the zip files of each module along with it's meta data.

That would be cool. Although I wonder how we'd then afford the storage if it gets popular. Seems like that could very quickly become expensive.

Honestly the way I've always imagined it is a giant, open, messy database filled with everything. And then a bunch of other scripts organizing it and consuming it in different ways. I'm not sure this solves your particular issue though, but it might be a way to design the architecture underneath it.

Yeah I like that! Just the DB for art, a simple form for submitting content and an api serving it out. But would you have any idea on how to set this up in a way that's affordable? Because something like heroku might be nice for initial testing, but I'm worried that any production version would not be able to run on free infrastructure.