This repository is for high-level planning of BigchainDB and allied projects.
See ROADMAP.md
High-level planning for BigchainDB and allied projects
This repository is for high-level planning of BigchainDB and allied projects.
See ROADMAP.md
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
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:
py-crypto-conditions
close to RFC-002 as with the JS and JAVA reference implementation @sohkai
bigchaindb/cryptoconditions
to py-crypto-conditions
@sohkaiinterledger/py-crypto-conditions
@sohkaipy-bdb-crypto-conditions
@sohkaiTimeoutFulfillment
to py-bdb-crypto-conditions
cryptoconditions#29 @sohkaiInvertedThresholdSha256Fulfillment
to py-bdb-crypto-conditions
cryptoconditions#30 @sohkaipy-bdb-crypto-conditions
cryptoconditions#24 @TimDaubilp-web-api
specification and get PR approved @sbellembdb-ilp-api
@sbellemjs-ilp-plugin-web
@sbellemIPDB test net usable by any 3rd parties
foo
Foo
foo
foo
Friday, foo date 1:
Friday, foo date 2:
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.
Bitcoin doesn't scale.
WIP
WIP
WIP
WIP
WIP
Friday, foo date 1:
Friday, foo date 2:
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.
Umbrella issue for all tasks related to open-sourcing 3D match.
etc.
IPDB test net usable by vetted 3rd parties
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
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.
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:
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:
The form of outcome of this project is a formal, practical, technical specification of SPOOL v2.0 using the above mentioned technologies.
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:
Last items before completing:
Added by Troy:
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.
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.
Creation
(project)Removed out of scope:
IPDB wants to be able to:
Moreover, IPDB users need a way to:
Some kind of IPDB User Dashboard would be nice.
Implement a reference implementation of COALA IP.
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:
Create a Python implementation of COALA IP that runs on top of an immutable ledger, such as IPDB.
Deadline: Wednesday, Aug. 17th
Future
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
IPDB live net usable by vetted third parties
foo
Foo
foo
foo
Friday, foo date 1:
Friday, foo date 2:
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.
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.
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];
}
})
pycoalaip
needs its repository, and perhaps renamingbigchaindb-coalaip
needs its repository, and perhaps renamingpycoalaip
packaging boilerplate to be able to pip install it -- just register on PyPIbigchaindb-coalaip
packaging boilerplate to be able to pip install it - just register on PyPIbigchaindb-driver
is usable/callable for a basic TXpycoalaip
implement REGISTER
-- upload on PyPI (COALAIP/pycoalaip#4)bigchaindb-coalaip
supports the above operation (REGISTER
), in an abstract/generic way -- upload on PyPIThe 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
).
docker
and docker-compose
can be used to run a bigchaindb
node. A ipdb-regtest
mode should be created soon for testing as well.
(WIP)
foo
foo
Foo
foo
foo
Friday, foo date 1:
Friday, foo date 2:
This ticket describes what is needed in order to wrapup the BigchainDB
integration with DACS:
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.
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
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.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:
bigchaindb
from most repo names: e.g. bigchaindb-jukebox
becomes jukebox
, bigchaindb-examples
becomes examples
bigchaindb-react-webpack-boilerplate
should be boilerplate-react
. Making future boilerplates with other tech like boilerplate-django
possible.driver-LANGUAGE
e.g for Haskell: driver-haskell
. That’s it. As such, bigchaindb-driver
should be driver-python
driver-nodejs
or driver-js
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.
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.
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.
This helps to expose the value proposition of ascribe, WOTN, and IPDB to major works in the cultural commons.
Foo
foo
foo
Friday, foo date 1:
Friday, foo date 2:
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.
Reduces the barrier to entry to populate IPDB with other cultural commons content.
Foo
foo
foo
Friday, foo date 1:
Friday, foo date 2:
Cool URIs don't change
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.
From @vrde:
how do you make sure that the data is true?
the only source of trust should be bitly
We now have (at least) 4 core python libraries, which may have heavy dependencies on each other:
And two higher level (~application) Python libraries:
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:
Review the draft documents at http://w3c.github.io/webpayments-ig/VCTF/ and demo their current demo.
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.
This is good for the cultural commons, and good driver for supporting rights statements and IPFS.
Foo
foo
foo
Friday, foo date 1:
Friday, foo date 2:
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 !
(WIP)
Open source the ascribe webapp.
Idea: Open-source individual Django apps, one at a time.
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.
WIP
foo
foo
Friday, foo date 1:
Friday, foo date 2:
Release a set of high quality front-end components to help us and others build apps, hopefully on top of BigchainDB.
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.
bigchaindb/react-components
repo that will house current and future componentsreact-components
Friday, May 6th Friday, May 20th:
Friday, May 13th Friday, June 3rd Friday, June 10th:
TODO:
Issue #310 was the prototype; this ticket takes it to production. This includes the need for an IPDB live net (vs. just test net).
WIP
WIP
WIP
WIP
WIP
Friday, foo date 1:
Friday, foo date 2:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.