Reference implementation of COALA IP

Abstract

Implement a reference implementation of COALA IP.

Motivation

Upgrading SPOOL to use our COALA IP spec allows us to be the forerunning implementation of the spec and set an example for other systems. COALA IP also provides enhancements on top of the current SPOOL architecture:

Based on LCC RRM for rights management
Usage of Linked Data
Compatibility with IPLD

Goals

Create a Python implementation of COALA IP that runs on top of an immutable ledger, such as IPDB.

Challenges

Custom Linked Data schemas will need to be hosted
Interoperability between Linked Data schemas and IPLD still need to be figured out:
- How to add IPLD hashing structures to a schema?
Queryability handling for ledgers

Tasks

Deadline: ~~Wednesday, Aug. 17th~~

Future

Wrapup DACS integration

This ticket describes what is needed in order to wrapup the BigchainDB
integration with DACS:

About this ticket:

The goal of this ticket is to collect all the tasks that need to be completed in order to finish DACS's integration with BigchainDB.
So if it turns out that the tasks (the sub list items) could be broken down into more fine grained tasks, then please make changes to this ticket.

Tasks:

IPDB test net usable by any 3rd parties

Abstract

IPDB test net usable by any 3rd parties

Motivation

foo

Goals

foo goal 1
foo goal 2

Challenges

Foo

foo challenge 1?
foo challenge 2?

Architecture

foo

Examples

foo

Tasks

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

Internal server error - 0.9.3 - MongoDB

Hi!

I facing "Internal server error" when i try to CREATE or GET details over transactionID. My transaction templace is fine, i try to first use the BigchainDB example to test if the error is my CREATE request, but when i try occurs the same...
My version is 0.9.3 with MongoDB 3.4, all starts fine, the access is unblocked to try.
http://cxxxxxxxx/api/v1

Thanks !

Review W3C Verifiable Claims Spec and Demo

Review the draft documents at http://w3c.github.io/webpayments-ig/VCTF/ and demo their current demo.

IPDB production net usable by any 3rd parties

(WIP)

Abstract

foo

Motivation

foo

Goals

foo goal 1
foo goal 2

Challenges

Foo

foo challenge 1?
foo challenge 2?

Architecture

foo

Examples

foo

Tasks

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

Add {Euro, DPLA, Met} corpora such that searchable in WOTN and in IPDB

Abstract

Like #289 but repeat for other key corpora. Take advantage of new infrastructure since then, namely #304 (API to add corpora). For sure include: Project Europeana, DPLA, and The Met. Potentially also British Library, Flickr, Wikimedia commons, and other CC licensed content too.

Motivation

This helps to expose the value proposition of ascribe, WOTN, and IPDB to major works in the cultural commons.

Goals

foo goal 1
foo goal 2

Challenges

Foo

foo challenge 1?
foo challenge 2?

Architecture

foo

Examples

foo

Tasks

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

Open source reusable React components for building front-ends on top of BigchainDB

Abstract

Release a set of high quality front-end components to help us and others build apps, hopefully on top of BigchainDB.

Motivation

As we internally build more apps (and example apps), a set of quality, self-contained front-end components helps us move quicker with less bugs. Open sourcing this component library will allow other developers to benefit from our work and help them build their apps. We're opinionated and like using React for our front-ends, so we recommend it to our friends too.

The goal is not to replace existing front-end component libraries like React-Bootstrap, Material-UI, React-Toolbox, or etc, but to provide additional, more involved, components that live on top of the basic UI components that these other libraries provide; for example, an uploader.

We've been secretly building this out as ascribe/react-components, but now it's moving to BigchainDB.

Goals

Create a bigchaindb/react-components repo that will house current and future components
Existing apps and demos should have their reusable components generalized and put into react-components

Tasks

~~Friday, May 6th~~ Friday, May 20th:

Upgrade dependencies to allow React 15 as a peer dependency
Create tiny boilerplate for initializing JS apps with Babel, Webpack, and React built in
Create JS utils library for non-React utilities
Overhaul ESLint configuration (also to help with BigchainDB's JS api)

~~Friday, May 13th~~ ~~Friday, June 3rd~~ Friday, June 10th:

Resolve outstanding pull-requests in ascribe/react-components
Implement theming, probably using react-css-themr
Create ascribe/ascribe-react-components, adding ascribe-specific components (ie. extended Properties, Buttons, some Onionboarding components)
Use components in ascribe/onion
Use components in bigchaindb/bigchaindb-examples
Move ascribe/react-components to bigchaindb/react-components
Publish to npm

TODO:

Finish documentation of components
Add unit tests for the easy stuff (ie. not uploader)

Documentation: Who is our audience?

The purpose of this issue is the address the question as stated in the title: Who is our audience?

Moreover, what knowledge do we assume our audience has. Example: do they need to be told how to install Python, pip?

This question was raised in PR bigchaindb/bigchaindb-driver#138 as some think that we are documenting too many things, and burying the essentials under too many details, which makes it more time consuming for the average developer to simply find what they need.

Seeking ideas to manage the different repos and versions so that it all works.

We now have (at least) 4 core python libraries, which may have heavy dependencies on each other:

bigchaindb (server)
cryptoconditions
bigchaindb-common
bigchaindb-driver

And two higher level (~application) Python libraries:

pycoalaip
pycoalaip-bigchaindb

This issue seeks to outline a clear workflow/procedure to ensure that we can keep on having fast release cycles meanwhile preserving the functionalities and proper behaviours of each component.

Some key things that need to be handled:

breaking changes in one or more libs
keeping in mind that eventually (hopefully) there will be multiple clients out of our control, and consequently the BigchainDB Server HTTP API is a contract with clients.

5 DACS demo images registered on IPDB

Abstract

If I go to whereonthe.net, and I search for an image that is in the DACS DB, then the results page should include a card that has metadata {title, artist, year, ascribe ID}, link to DACS, and link to ascribe.

Motivation

For creators: a new means to get proper attribution, and license their work. For web surfers: a means to see who has rights to an image. For us: high value prop for DACS because of attribution & licensing.

Goals

Upload DACS data to IPDB

Define implementation roadmap (https://github.com/ascribe/specs/issues/29)
Build scaffolding for each project: COALA service, COALA models, COALA BDB plugin, BDB driver(https://github.com/ascribe/specs/issues/36)
Decide on notion of ownership for Creations (COALAIP/pycoalaip#6)
Define REST API contracts (milestone)
Define pycoalaip API contract (COALAIP/pycoalaip#3)
Define pycoalaip-bigchaindb API contract (COALAIP/pycoalaip-bigchaindb#2)
Implement the registration of a Creation (project)
Images get registered from us on IPDB using pycoalaip (https://github.com/ascribe/memetracker/issues/17)

Removed out of scope:

~~Create backend boilerplate (https://github.com/ascribe/specs/issues/30)~~
~~Investigate interoperability between Django and pycoalaip~~
~~Support IPLD in BDB (bigchaindb/bigchaindb#485)~~
~~Branch out and implement other use-cases~~

Build WOTN cards to support use case

Scrape DACS data
Add data to WOTN and image-match
Build WOTN card
Push to production
Add the registration transaction's id as meta data to the image (https://github.com/ascribe/memetracker/issues/16)
Show transaction id in UI (https://github.com/ascribe/memetracker/issues/11)

Targets:

Finish scaffolding by Tuesday, Aug. 9th
Support DACS cards in WOTN by Monday, Aug. 15th
Finish defining full API contract by Monday, Aug. 15th
~~* Implement working registration API by Sept. 1~~ (and continuing work afterwards as needed)

CC FR Project : How to use schema.org and Ascribe REST API to claim creative work fair use on a website

Hello,

In the next weeks, I will try to use CC FR Project (http://cc.ascribe.io), schema.org (https://schema.org/CreativeWork), and Ascribe REST API (http://docs.ascribe.apiary.io , http://docs.ascribe.apiary.io/#introduction/overview) to claim "Fair use" for pictures published on one website.

Goals :

1 - use schema.org to give licensing datas to search engines, Google, Bing and Yandex - see if datas are displayed when a picture is found on them.

2 - give information to the website visitors on how to fair share pictures published with CC-BY-NC-ND-4.0: Attribution-NonCommercial-NoDerivs 4.0 International (https://creativecommons.org/licenses/by-nc-nd/4.0/ - FR : https://creativecommons.org/licenses/by-nc-nd/4.0/deed.fr )

I will push here the job progress.

Thanks,

Eric

DOC :
https://creativecommons.org/licenses/?lang=en

project naming

We have a highly inconsistent naming scheme for our repos which in turn makes it hard for new visitors to quickly scan what we have, hindering discoverability:

bigchaindb in name: this is mostly redundant cause we have that namespace as org already, making something like bigchaindb/bigchaindb-whatever longer than needed.
driver names: sometimes driver in there, sometimes not, sometimes language at beginning, sometimes at end. A name like bigchaindb-hs makes it look like it's the server but written in Haskell.
detail tech in repo name, e.g. bigchaindb-react-webpack-boilerplate
js-* named repos are actually Node.js projects like the new driver so it’s a bit misleading making people expect vanilla JavaScript.

My suggestions:

Generally, name should be as short as possible, ideally just one word
Remove bigchaindb from most repo names: e.g. bigchaindb-jukebox becomes jukebox, bigchaindb-examples becomes examples
Only the server keeps its namespace to make it clear this is the real thing and this is what everything else is connecting to. So makes sense from branding perspective too
Put what the project is doing at first place, not the tech it's written in. With all of the above suggestions combined, bigchaindb-react-webpack-boilerplate should be boilerplate-react. Making future boilerplates with other tech like boilerplate-django possible.
All drivers follow this structure: driver-LANGUAGE e.g for Haskell: driver-haskell. That’s it. As such, bigchaindb-driver should be driver-python
Node.js driver should be driver-nodejs or driver-js
exceptions for all suggestions are repos which require special naming because of external requirements, like stylelint-config-bigchaindb, ilp-plugin-bigchaindb

With those suggestions I also have the folder structure in mind when someone clones multiple repos into one bigchaindb folder, mirroring the github namespace. So all drivers would end up beside each other, making folder easier to scan too:

vs.

one more thing: driver vs. client

From my naive non-programmer viewpoint driver is weird. Drivers are what I install to get a printer running on my machine. Isn’t client the term actually describing what the BigchainDB drivers do? If so, rename all driver repos to use client-*

Thoughts? Suggestions? As a good example to follow, just take a look at how clean and easy to scan this org page is: https://github.com/serverless

Don't want to introduce super strict rules here, but rather make everyone a bit more aware when naming projects. Yet the driver repos are really important and I would assume one of the first things devs are looking for when starting to build.

IPDB User Authorization, Monitoring and User Dashboard

Was bigchaindb/bigchaindb#779

IPDB wants to be able to:

ignore HTTP requests from unknown users
revoke HTTP API access by known users (e.g. if they behave badly, or they reach their quota)
measure who is making the HTTP requests (e.g. for monitoring and billing)

Moreover, IPDB users need a way to:

get or set authorization credentials/tokens
see how they are doing, e.g. how many HTTP API requests they've made in the past day, week, month, etc.
do more in the future

Some kind of IPDB User Dashboard would be nice.

Notes

this is independent of BigchainDB Server. We shouldn't be modifying BigchainDB Server to accomplish any of the above.
BigchainDB drivers may require some new extra methods or plugins to make it easier to work with IPDB.

Open source 3D-match

Umbrella issue for all tasks related to open-sourcing 3D match.

Review current state of code
??

etc.

CC FR Project login vs www.ascribe.io login : Licence selector not displayed

Hello,

When login through : https://cc.ascribe.io/?lang=fr
license (Creative Common) should be selected.
Whereas login through : https://www.ascribe.io/app/login
no license selector is displayed.

It's a bit confusing.

Work registered through https://www.ascribe.io/app/login : https://www.ascribe.io/app/pieces/27232
Then deleted (No license in the workflow - or I've missed something).
And then registered through https://cc.ascribe.io/?lang=fr and licensed : https://www.ascribe.io/app/pieces/27233 .

Thanks,

Eric

Support CC FR Project; including CC licenses & IPFS in ascribe.io app

Abstract

The CC FR Project has specific needs for extending cc.ascribe.io. The main ones are:
-rights statements (beyond the current support for CC licenses), just as project europeana uses. As developed by Paul Keller / Kennisland
-as an option instead of AWS S3 buckets, the possibility to use IPFS to store media. Note that it still needs some physical storage medium. One option is to have an IPFS node running on each IPDB node. Another option is to keep using S3 buckets, but have IPFS based disintermediation.

Motivation

This is good for the cultural commons, and good driver for supporting rights statements and IPFS.

Goals

foo goal 1
foo goal 2

Challenges

Foo

foo challenge 1?
foo challenge 2?

Architecture

foo

Examples

foo

Tasks

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

Interledger Roadmap to v1.0

Engagement with ILP allows BDB to partake in the overall ILP network, and provides driver functionality out of the box

See https://docs.google.com/presentation/d/1uguhPmuCUmV7JcJYL5ZNnbjIOqb7ApFOluA1pFhjh1Q/edit#slide=id.g179fd8610f_0_87 as supporting documentation

To get there we'd need to do the following:

WOTN : 500 Internal Server Error with non ascribe.io picture url

Hello,

I'm testing ascribe.io + whereonthe.net .

While checking one picture with original url from my website , I get :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.</p>

Whereas checking the same picture, but, with https://xxxx.cloudfront.net/live/yyyy/digitalwork/zzzz.jpg url picked on ascribe.io, I've got a 200 response with results.

I have tested with pictures randomly picked on the web, some gives 200, others 500 or 502 responses.

Any help ?

Thanks,

Eric

New onboarding process for Ascribe

See the old ticket in ascribe/products for details.

Progress

See ascribe/onion-boarding.

IPDB production net usable by vetted third parties

Abstract

IPDB live net usable by vetted third parties

Motivation

foo

Goals

foo goal 1
foo goal 2

Challenges

Foo

foo challenge 1?
foo challenge 2?

Architecture

foo

Examples

foo

Tasks

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

Internal production network (cluster)

Abstract

Issue #310 was the prototype; this ticket takes it to production. This includes the need for an IPDB live net (vs. just test net).

Motivation

WIP

Goals

WIP

foo goal 1
foo goal 2

Challenges

WIP

foo challenge 1?
foo challenge 2?

Architecture

WIP

Examples

WIP

Tasks

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

Idea for eating our own dog food: Persist shorted links on IPDB

Persist shorted links on IPDB

Cool URIs don't change

Tim Berners Lee: https://www.w3.org/Provider/Style/URI

Since I'm in lack of time, this is a super quick write down of an idea I had.

TL;DR: URL shortening is breaking the web. I'm sure someone said that before. There ya go. Build [your favorite browser] plugin that crawls your current page looking for href=bit.ly|.... Resolve link, generate an BigchainDB transaction output where PublicKey(b'[bit.ly link you just crawled]') and asset data being the link resolved from the short link. Submit transaction to IPDB. If e.g. bit.ly ever goes down, IPDB is backup. You can query by link, just search for: PublicKey(b"[bit.ly link you're looking for]") using the outputs endpoint. Thx @r-marques for public key indexing idea.

Problems

From @vrde:

how do you make sure that the data is true?
the only source of trust should be bitly

Maybe: https://tlsnotary.org/ ?

API on WOTN for others to add new DB corpora

Abstract

This generalizes on the learnings of #289: make the DACS DB searchable from WOTN and in IPDB to make adding corpora accessible to anyone, and easy for us with new corpora.

Motivation

Reduces the barrier to entry to populate IPDB with other cultural commons content.

Goals

foo goal 1
foo goal 2

Challenges

Foo

foo challenge 1?
foo challenge 2?

Architecture

foo

Examples

foo

Tasks

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

Technical spec for COALA IP Spec using LCC, IPLD, and BigchainDB

Abstract

With the SPOOL protocol, ascribe.io published and implemented a specification on how to handle ownership of digital assets on the Bitcoin blockchain. In the implementation of this, frameworks for digital rights management (most notably from LCC) were discovered that they couldn't be applied to SPOOL protocol v1.0 easily. As ascribe.io wants to move to BigchainDB as a ledger in the near future, this gives a rationale to formally discuss how the integration of Linked Data Coalition's Rights Reference Model could look like using BigchainDB as a central but decentralized rights registry.

Goals

Using the following (but not exclusively) technologies/resources:

we want to come up with a practical (!!!) technical specification that matches the use case of digital rights management (SPOOL v2.0) on a central but decentralized rights registry (namely BigchainDB).

In terms of actual goals, this means:

Converting parts of The LCC Rights Reference Model
to a JSON schema
Linking data between JSON schema entities using IPLD & JSON LD

Tasks

The scope of this project is to resolve the following tasks and questions. For now the scope of the project is deliberately kept to a time span of two weeks:

Identify vital components for a first-cut SPOOL v2.0 implementation
(which LCC entities are actually of use for us now)
Identify how LCC entities can be converted to a sane JSON schema using schema.org, when applied to digital rights management on a decentralized
registry
Research how linked data (both JSON LD and IPLD) can play a role in
linking pieces of meta data to assets
Write a comprehensible, fun, easy-to-read, specification that covers
how the above mentioned technologies can be used to implement a first-cut
implementation of SPOOL v.2.0
Update specification to reflect Creation ownership decisions (COALAIP/specs#6, COALAIP/specs#3)

Form

The form of outcome of this project is a formal, practical, technical specification of SPOOL v2.0 using the above mentioned technologies.

Outlook

As the Abstract already foreshadows, this project is rather extensive featuring many branches that could be traversed in-depth. Hence, it is even more important to stress that this projects overarching goal is to extract a practical implementation from the LCC standards body. Even if this means that the implementation in its first, second or third cut will not even closely resemble the original specification's outlines.

Hence, in future iterations (NOT NOW!) we'll worry about questions like:

How does this interplay with technologies like BigchainDB, IPFS, (InsertTechnology)
(more later when I get them :D)

Last items before completing:

Last passover by Greg
Final read through
Move to Coala organization

Added by Troy:

Remove the "when: In progress" label and close this issue

COALA IP: End to end implementation of Creation registration

Abstract

Create a solid foundation for all the layers of COALA IP for us and DACS to build on. Creation registration is the first step to everything, hence the choice.

Goals

Implement full Creation registration functionality across the entire stack, culminating in a passing integration test that traverses the following layers:

![Alt text](http://g.gravizo.com/g?
digraph G {
aize ="4,4";
"http-wrapper" [shape=box];
"http-wrapper" -> pycoalaip;
pycoalaip -> "bigchaindb-coalaip";
"bigchaindb-coalaip" -> "bigchaindb-driver";
subgraph cluster_bdb {
"bigchaindb-driver" -> ipdb;
ipdb [label="IPDB/BigchainDB"
graph[style=dotted];
}
})

Phases

Phase I

pycoalaip needs its repository, and perhaps renaming
bigchaindb-coalaip needs its repository, and perhaps renaming
Choose licenses with @gmcmullen help 😄

Phase II

pycoalaip packaging boilerplate to be able to pip install it -- just register on PyPI
bigchaindb-coalaip packaging boilerplate to be able to pip install it - just register on PyPI
bigchaindb-driver is usable/callable for a basic TX

Phase III

pycoalaip implement REGISTER -- upload on PyPI (COALAIP/pycoalaip#4)
bigchaindb-coalaip supports the above operation (REGISTER), in an abstract/generic way -- upload on PyPI
Create HTTP wrapper for pycoalaip that exposes Creation registration (bigchaindb/coalaip-http-api#1)
Fix cross project dependencies to their uploaded PyPI versions
Write documentation on usage for DACS

Notes

The API test assumes that the underlying dependencies (direct and indirect) work as expected. In other words, pycoalaip is assumed to work as expected, just so as the others (bigchaindb-coalaip, bigchaindb-driver).

Testing infrastructure

docker and docker-compose can be used to run a bigchaindb node. A ipdb-regtest mode should be created soon for testing as well.

CLA signing

We need some way to manage this so that we can quickly merge new contributors' code.

The ideal would be an automated solution, such as https://cla-assistant.io/ or https://clabot.github.io/

Either way, maintainers need to be able to know whether someone has signed the CLA or not, and when that is not the case, maintainers need to know the procedure to follow in order to on-board a new committer.

IPDB test net usable by vetted 3rd parties

Abstract

IPDB test net usable by vetted 3rd parties

moved to different repo

Open-source ascribe.io front & back end

(WIP)

Abstract

Open source the ascribe webapp.

Idea: Open-source individual Django apps, one at a time.

Motivation

We have no desire to keep it closed. By open-sourcing it, we make it easy for others to create their own custom frontends and backends, by changing whatever they like, without dependence on us.

Goals

Open-source frontend
Open-source backend

Challenges

WIP

Make sure we don't expose private keys (should be straighforward)
How to handle when our backend currently spends bitcoin, and uses other 3rd party web services that cost $ ? (should be straighforward)

Architecture

foo

Examples

foo

Tasks

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

Internal testnet

Abstract

This is a prototype to: Connect all the dots between ascribe.io webapp and IPDB, such that IPDB replaces the hashes in Bitcoin, and metadata stored in SQL too (but not the user & app maintenance data in SQL). Maintain owner = private key property of Bitcoin.

IPDB should be running a test net that isn't just local. It only needs to be good enough to trust ascribe.io, it doesn't need to worry about vetted third parties or arbitrary 3rd parties. That's for later tickets.

Follow-up tickets include: production ascribe-IPDB (#288), then opening up IPDB test & live nets to 3rd parties.

If there are >1 possible architectures, take the time to explore them, at least at a high level.

Motivation

Bitcoin doesn't scale.

Goals

WIP

foo goal 1
foo goal 2

Challenges

WIP

foo challenge 1?
foo challenge 2?

Architecture

WIP

Examples

WIP

Tasks

WIP

Friday, foo date 1:

foo task 1
foo task 2

Friday, foo date 2:

foo task 3
foo task 4

bigchaindb / org Goto Github PK

org's Introduction

bigchaindb / org

org's People

Contributors

Stargazers

Watchers

Forkers

org's Issues

Abstract

Motivation

Goals

Challenges

Tasks

About this ticket:

Tasks:

Abstract

Motivation

Goals

Challenges

Architecture

Examples

Tasks

Abstract

Motivation

Goals

Challenges

Architecture

Examples

Tasks

Abstract

Motivation

Goals

Challenges

Architecture

Examples

Tasks

Abstract

Motivation

Goals

Tasks

Abstract

Motivation

Goals

Upload DACS data to IPDB

Build WOTN cards to support use case

Targets:

one more thing: driver vs. client

Notes

Abstract

Motivation

Goals

Challenges

Architecture

Examples

Tasks

Progress

Abstract

Motivation

Goals

Challenges

Architecture

Examples

Tasks

Abstract

Motivation

Goals

Challenges

Architecture

Examples

Tasks

Persist shorted links on IPDB

Problems

Abstract

Motivation

Goals

Challenges

Architecture

Examples

Tasks