The demo page is now seeding 24/7, and Fuseki is also running 24/7, but still not updating its RDF blockchain in real time (it sits now on block 1205200 approx).
The linkage is crude, needs to be refined to use an async messaging facility instead of just bash shell. (I'm even toying with the notion of running the three processes each on a separate machine, make each process resource-independent of t'other if the context turns out to require it.)
I've experienced a couple of build-ups of hung blocknotify calls (both the Datacoin ACME and the Slimcoin ACME) that I've had to clear - but only on the server. I'm fairly sure that Fuseki needs more compute resources than I can give it on that particular m/c and, if I can't find the information on teh webz, I'm hoping to beg a favour from my ex-colleagues (who wrote Jena and Fuseki and who are now collectively
epimorphics) for some help in setting up Fuseki with properly adequate compute resources for the task.
It sounds as if the
blocknotify script isn't functioning properly. If you're running a standard Python dev setup (i.e. using a virtual environment), then you can run the shell and Python scripts in
${ACME}/scripts and the test scripts in
${ACME}/acme/tests (which have debug and test boolean flags for this purpose).
All power to your elbow and deep, deep apologies for the scrappy nature of the ACME codebase (it started off as pure RPC, then I found I needed to bolt on a persistent storage for somewhere to create and store the address index).
I experienced similar torrenting problems which is what prompted me to change tack to use an (assumedly, community-curated) RDF graph --- because depending on random arbitrary strangers for curating one's content isn't necessarily the most reliable approach.
ATM, I'm looking at available ways of signing graphs - there's one
built-in to RDFLib:
the isomorphic graph has a special method called graph_digest() that will output a graph-level hash using the Sayers and Karp algorithm.
. Now I have to dig around in 3rd-party javascript RDF libs to see if I can find an equivalent to RDFLib graph's graph_digest() so that I can independently check the hash signature.
ACME is only a fledgling, just wait until it matures ...
the ability to federate queries out to SPARQL endpoints is a really useful facility (
https://www.w3.org/TR/sparql11-federated-query/) for example, to query dbpedia directly without first loading dbpedia into a local triple store (which may take some time)
(from the RDFLib issue list)
If you mentally switch out dbpedia in favour of say, d5000economicsgroup or muf18andfriends or thesphericalhorse - doesn't have to be just one ACME, can be many, the graph is
directly and immediately shareable in part or in whole, in triples or in SPARQL query results. This federated query thing could be a really big deal for ACME and afaik, is unique to RDF.
Cheers
Graham