Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 44. (Read 137085 times)

Ok so we have synced explorer.

Interesting analysis they provide on largest wallets. Very interesting

https://chainz.cryptoid.info/slm/#!wallets

I think so too, I really like features of this explorer.

Well worth it though, good job. The rich list is something of a revelation but is very useful to know, as the size of the disproportion will act to severely inhibit further development.

Cheers

Graham

55 euro for 6 months I paid about 50 for 5 months 7 days, because I didnt have more crypto at my exchange xD.

Great, thank you
How much does it cost ?

K.

Thanks Graham for the clarification. I guess I will wait then with an own instance (now that we have another block explorer), but perhaps I'll download your current experimental version to play around with a bit. Perhaps this way later I can help with testing, knowing the ACME app a bit better.

Federated graphs is a topic I still don't know much about, so I'll have to read a bit

I still haven't grasped fully how your "blog post app" works - is the source code available somewhere? (Edit: After re-reading you post, I think its clearer now). Which RDF vocabulary do you use for blog posts, something solid-related (or simply Dublin Core)?

@muf18: Thanks! I like CryptoID a bit better than Bchain. Once it has synced I'll try to test the proof-of-burn blocks.  

I've improved the "Slimweb Gateway" a bit, now it looks a little bit better, has a little bit of text and can accept GET requests with addresses. The next step would be to set up a new good-looking test/presentation Slimweb page and host it permanently, so people see the concept really works My old VPS hoster unfortunately didn't like my (permanently seeding) torrent client, but I'll soon set up a new one without restriction in his terms & conditions, so I should be able to host it there.

https://chainz.cryptoid.info/slm/

Syncing now . Big thanks to service of CryptoID, and my little contributions with small payment .

It needs a substantial re-write: the processing of new blocks, triggered by blocknotify, needs to be handed off to a messaging system so Fuseki updates can occur asynch. The current "block explorer" presentation is too taxing of the client RPC-API but, seeing as that part of the code was hacked updeveloped before the Fuseki side (which I only really bolted on in order to be able to show address listings), that's hardly surprising. I'm not sure ACME even caches its results - which it should do, there's plenty of opportunity for speedups and loadlightening.

The re-write should also result in a clarified architecture which should be readily transposable into a javascript implementation - it's just an MVC web app at heart, listens for blocknotify, calls the client API to get the JSON output, maps it into RDF and pushes the RDF over the wire to Fuseki. It's Fuseki that should be driving ACME, not the client. So, current performance is poor, the code is brittle and makes far too many assumptions of convenience. For an idea of what's on offer in terms of browser, javascript and RDF, there are some working examplesin the DOACC documentation... e,g, click the "Start" button on:

https://doacc.github.io/techniques/querying.html
(there're more examples to check out (and pick up some basic info on using RDF to model a cryptocurrency and its blockchain), it's all front-end, the graph is a file, loaded into the browser, the javascript libraries handle the on-the-fly queries locally - in the complete version, it'd be aiming its SPARQL queries at an instance of Fuseki.)

I too am in the process of provisioning a more capable server which I can use to test out a "click'n'drool" deployment solution so that anyone can set up a Slimcoin ACME in the cloud. It'll get interesting when we start to want to link the different ACME-hosted RDF graphs together, so that SPARQL queries can be posed of a federated graph (i.e. queried as one BFG - "Big F'ing Graph") which I hope will help ACME-hosted RDF graphs of published content to avoid inadvertently becoming walled gardens (np if it's intentional but shouldn't be that way by default, is all).

I have a use case which is acting as a focus for my activity - I'm intending to activate the javascript in the other tabs of the micro-app that presents "A different perspective on cryptocurrency" and populate the "Index" with a js-generated listing of prior blog posts (https://web.archive.org/web/20121125014835/http://bel-epa.com:80/posts/) that I wish to curate using this new approach. I curate my posts in XML (Docbook 4.5) and store them in a native XML database so mapping them to RDF will be trivial, I have a small XSLT stylesheet that fishes out the abstract for each post and programmatically constructs a listing - which is basically what I did to produce the rendered HTML that you see). All that should drop straight into RDF with minimal fuss - largely because that activity is exactly what the underpinning XML/RDF technology was designed to support.

Horses for courses, spherical or not.

Cheers

Graham

For now I have paid for 157 days for chainz explorer, which should be up within this week (owner of it is a legendary user on bitcointalk), so I hope they will cope with PoB blocks (I have sent PoB block example and how it is represented on bchain explorer).
I think chainz is a very good altcoins explorer, and it has some unique features, which other block explorers doesn't have, that's why I choose it.

Let's see how this work out.

Done. I created a Wiki article, so people can add their own nodes (only they must register at Github) and other ones they know about, and it's easier to update it.

About block explorer: Yep, I saw these glitches at bchain.info several times. I think it struggles with the Proof of burn blocks. I may try to set up a full ACME instance soon (I'm about to change to a bigger VPS for my Slimcoin activities, and an ACME instance probably would fit), but I can't guarantee it. Perhaps Graham can comment how "stable" ACME is until now and what bugs/problems are to be expected. I noted the test ACME instance generally working well.

OP please update nodes

https://justpaste.it/6p8mp

Btw. - there is still on-going problem with bchain explorer - I have seen that apart that it can't access some addresses, sometimes it's counting wrong tx's, for example not counting all.
I had such example - on address there is more SLM's than there is displaying in explorer (it's on main chain - there wasn't any fork - and I checked it with bchain's block hash - merkleroots and diff is correct).

As such I think we should deploy our own blockchain explorer.

Yes I posted a link to the wiki.
It was a month ago I think, so it could get messed up with lots of other messages now.

@muf18: I looked at the Telegram group, but didn't find your contribution there in the last 3 days. You posted the wiki article link, right?

I don't know what could be "biased" there. The only items where Slimweb is depicted a little bit more positive than Shift are censorship resistance (Shift's whitepaper in section 5.3 affirms that "illegal" content will be censored) and the more centralized nature of gateways, but the remark I made there ("only publishers using the "official" gateway can use all features") is a summary of a paragraph of their Whitepaper.

I think Shift surely has also advantages with respect to a Web2web-based approach. Performance came into my mind - in Slimweb, we search the public torrent network for Slimweb pages, which is more resource-consuming and slower, while Shift may have advantages searching only in their "private" swarm.

(Anyway, reading the contributions on the Shift Telegram group, unfortunately it confirmed my prejudices about this kind of chat groups and it didn't really incentive me to join and discuss there. If a discussion emerged at a less chat-like forum like Reddit or here, no problem, I would have contributed.)

You can try to join telegram group on SHIFT. When I have pasted your link to comparison of "services", they said it was biased or heavily biased towards Slimcoin .
I tried to explain it, but it was hard to change attitude to see different approach. Maybe you could make it more clear .

It was a Shift user which asked me for an opinion about Shift per PM. Later he wrote to the Shift developer and he more or less confirmed my doubts about current decentralization issues, but wrote that the Shift team aims to solve these problems in the future. He claimed that they're already working on a solution for the "unique dApp owner" problem.


Yep, that would be cool. In theory, there should be no problem with Namecoin domains pointing to Slimweb websites via gateways. Reading Namecoin's specification superficially, I haven't found out they can directly point to an arbitrary URL, something like: but if that doesn't work, gateway owners should simply be able to point subdomains like to the GET request using a .htaccess entry with wildcards.

(Currently, the example with the GET request still doesn't work, the gateway would have to be "modernized" for that, as it currently only accepts the address as an entry in the form field.)

Ok thanks.
With whom did you speak about SHIFT? Seriously it was my first project I have stumbled upon reading about decentralized web content more than a year ago.

Could we try to work with namecoin's .bit domains?

They seem to use it like Counterparty - to "bootstrap" a new cryptocurrency and distribute them to people "burning" another one (in this case, people burning Blackcoin get Blacknet coins). That's completely different from Slimcoin's "PoB as block generation mechanism".

In the Qora thread I read that they are planning to include a PoB mechanism a bit similar to Slimcoin's. But it seems more a long-term goal. I'm not following them closely though.

Formerly blackcoin will become blacknet. Intention to use PoB

http://blacknet.ninja/burn.html

Oops. So the link was wrong about a year now ... Done!

I just had a discussion about Shift (the decentralized web project based on a Lisk fork). Basically, the outcome affirmed, for me, that the way we're going with Slimweb/Web2Web is the right one.

Shift is a cool project, it is maybe currently the one closest to the goal of achieving a torrent/IPFS-based web readable with a simple browser, much closer than TRON. But it has a number of aspects that are not completely decentralized - for example, the Phantom app, which provides most services, runs on a sidechain with an unique owner, and if the owner's keys are lost or get seized (or hacked) the project is close to failure. Gateways and DNS-IPFS "connections" are also currently centralized; they can be decentralized but are rather complex and resource-consuming.

A set of simple KISS tools, like Web2Web, is much easier to decentralize, as everybody can host every component of the system on a cheap VPS of $2-3 or on his own Raspberry Pi. DNS integration would also be easy: simply link with a CNAME entry to a JS gateway providing the address as a GET parameter.