I looked into the projects, you are contributing now, and I find Datacoin, quite interesting. Would it be a problem to merge our codebases into one ?
As I mentioned earlier, I was investigating Datacoin because I was interested in finding out more about how the metadata was handled. With Datacoin, you could run apps straight out of the tx data. Could easily put a lightweight client in there, as binary.
Iff you had metadata. You'd have to trust the address of the publisher and that could be conducted in a separate side channel and you could find out the metadata that way. But it's fragmentary, needs to be collated, so I adapted an ACME to check whether it worked in practice - and also get a sense of how much use was being made of that facility (elsewhere this is called market research).
As
quid pro quo, I'm having a go at contributing an upgrade to a later codebase (aka gaining experience). It's what I do. I'm also contributing to Beecoin and Helium, have contributed to BelaCoin, Sprouts, PIVX, the list stretches right back to Feb 2014.
I have been quite specific, I'm a contributor and it would be a mistake to consider me as the dev for two reasons, the first is because it runs counter to Teal principles - to have a dev is a centralisation influence, the second is because this influence tends to create a central point of (all too human) failure, the very opposite of what was intended. This is a shared resource with shared responsibilities (if it's to sustain itself).
The Slimcoin network is recovering from its Nov 2016 all-time low, the engine's somewhat idiosyncratic-but-not-entirely-unpredictable behaviour is now more widely appreciated and some apparently reliable workarounds exist. By reference to the
networks that cryptopia can apparently see, the Slimcoin network is positively glowing with health:
(It is entirely possible that they under-report as much as novaexchange does for Slimcoin nodes https://novaexchange.com/addnodes/SLM/ but even if that is the case, ~40 nodes is still pretty healthy in context.)There a number of GUI improvements in development, including an incomplete but functioning implementation of watch addresses. The torrenting aspects of web2web publishing proved tedious and torrent metadata is solely concerned with transport and reconstruction of resource fragments, it doesn't even record the mime type of the torrented resource, instead that task is devolved to torrent trackers.
The protocol doesn't really matter, if you're publishing content then if you're not hosting it yourself, someone else is on your behalf. ACME is aimed at allowing club members an alternative to torrenting / coughing up Bitcoin to have content hosted on IPFS. Run your own, share one with others, do as you see fit, there's no constraining cryptographic inheritance here, feel free to be as disorderly and rambunctious as you like.
I have an old blog in XML that I'm planning to render as HTML with base64-encoded resources, I just have to work out a metadata scheme (i.e. set of RDF statements) that I can store in the associated metadata+content graph, which I can then use to feed to javascript to get it to programmatically populate the other tabs of the standalone A different perspective post, turning it into a micro standalone blog app (with safely-embedded javascript libs + Semantic-UI css framework) with a list of past posts, titles, dates, abstracts, etc. which can be rendered in the wallet as a Qt-driven specialised in-wallet blogging app or the same thing as a component of an ACME instance, wherever hosted. Hey, twitter started out small.
Cheers
Graham