Slimcoin | First Proof of Burn currency | Decentralized Web

[d5000]

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.

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.

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

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:

Code:

slimco.in/gateway.html?url=SgNoXUGXYRJ3yvfAFReMQGDrUGFuY8HEBu

but if that doesn't work, gateway owners should simply be able to point subdomains like

Code:

SgNoXUGXYRJ3yvfAFReMQGDrUGFuY8HEBu.slimco.in

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.)

[muf18]

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.

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.

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

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:

Code:

slimco.in/gateway.html?url=SgNoXUGXYRJ3yvfAFReMQGDrUGFuY8HEBu

but if that doesn't work, gateway owners should simply be able to point subdomains like

Code:

SgNoXUGXYRJ3yvfAFReMQGDrUGFuY8HEBu.slimco.in

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.)

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 .

[d5000]

@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.)

[muf18]

@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.)

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]

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.

[muf18]

OP please update nodes

https://justpaste.it/6p8mp

[d5000]

OP please update nodes

https://justpaste.it/6p8mp

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.

[muf18]

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.

[gjhiggins]

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.

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

[muf18]

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

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

[d5000]

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.

[keliokan]

Great, thank you
How much does it cost ?

K.

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

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

[muf18]

Great, thank you
How much does it cost ?

K.

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

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

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

[gjhiggins]

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

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

[muf18]

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

[muf18]

Ok so we have synced explorer.

Interesting analysis they provide on largest wallets. Very interesting

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

[muf18]

With little time and new explorer with great features we can estimate, which wallets are known to be wallets of Coinsmarkets scammers.

https://chainz.cryptoid.info/slm/wallet.dws?75580.htm

I'm 99% this is for sure wallet of them.
So they hold in on 106K of SLM. Great for another scammers... I'm sorry I even messaged about listing us, it's my fault, I didn't research it enough.
I have seen that this exchange has strange UI/UX, but I thought that 1+ year experiance is "good enough" - it isn't.
I'm very sorry for this. That shouldn't happen. That's why now, when I inquiry any exchange, I do it very carefully, and don't go with some new, untrusted, and unknown exchanges.
About freiexchange - I'm confident enough to say, they rather should be trusted, they are supporting as coin similar to us in terms of marketcap, and they have running this exchange for almost 2 years now.
I don't know about Novaexchange now - it's in new hands, they say it's in "better hands", but I can't say anything about it really.

Btw. - blocks are faster then they should - averaging on about 75 sec.

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

[muf18]

Editted and updated topic at https://cryptocurrencytalk.com/topic/11782-slimcoin-first-proof-of-burn-currency-decentralized-web/

Updated important files: https://github.com/muf18/Slimcoin-important-files

Slimcoin Wallet AIO (block 1461500) : https://mega.nz/#!hq4T1AbY!4O5w3WWWQmRMfdoyxCY1_Hwfgs0fUW0lNJ2gsi_i4jQ

Is there anywhere MacOS binary of 0.5.1 version (which had fixed client, which wouldn't crash after receving/calculating burn hashes) ?

https://www.reddit.com/r/slimcoin/comments/955xcg/development_of_slimcoin/

[yyz13857180757]

Obviously, people are interested in the development of Slimcoin, and the team must seriously consider the future of the project.It is necessary for the team to strengthen the market value management.

[dzarmush]

Obviously, people are interested in the development of Slimcoin, and the team must seriously consider the future of the project. It is necessary for the team to strengthen the market value management.

It's up to everybody, up to us. Unfortunately the whole market is down, people have losses instead of gains, so there's not much money for marketing. Let's hope it'll change soon so we'll have more resources.