There's a thought (and a question) I had a while back, but that came back to mind today as I was thinking about all the things that could be built upon the BitShares platform (happens to me a lot ), and which is the following:

would it be a lot of work to implement some sort of access control to the RPC calls to the client?

I originally had this question when using a small RPC proxy to the client to be able to do some Ajax calls from a webpage, however I didn't feel very comfortable that this proxy had unrestricted access to my client (which was also running my delegate at the time).

There are also the tools that I'm working on, which (understandably so) people don't necessarily feel comfortable running (unless properly reviewed before) as it could easily steal their private keys if having access to an unlocked wallet.

Something like that would be nice in the config.json file

"rpc": {
    "enable": true,
    "users": [
        {
            "rpc_user": "web_client",
            "rpc_password": "password1",
            "rpc_methods_allowed": ["get_info", "about", "blockchain_get_blocks"],
        },
        {
            "rpc_user": "bts_tools",
            "rpc_password": "password2",
            "rpc_methods_allowed": ["get_info", "blockchain_get_delegate_slot_records", "wallet_publish_feeds"],
        }
    ],
    "httpd_endpoint": "127.0.0.1:5678",
}

maybe also having the "rpc_methods_forbidden" property would be nice, which would allow things like:

"rpc_methods_allowed": ["*"],
"rpc_methods_forbidden": ["wallet_dump_private_key"]

although it's generally better to always whitelist instead of blacklisting methods, so we could probably do with only "rpc_methods_allowed" at the beginning.

I know that there are other priorities right now in the development of the wallet, but if this is not too much work, I think it'd be very nice to have (probably this also could help for integration in gateways, as it would allow to have a python/php/... interface to the client which has limited access to what the client can do)

as a Christmas gift (and a way to hopefully get voted in ), on top of developing the tools, I also hereby pledge to set up and maintain 2 chain nodes in each major geographical region (US, Europe, Asia) for a total of 6 chain nodes for as long as I am voted in.

This will make initial sync with the network much faster!

It is called brainstorming.  Not all monetization ideas are good, but you need to allow yourself to think outside the box.

Sure, please keep thinking in the open as you always have, if there's something I love about this community and you guys is the openness and the freedom of thought / talk in the forums (and the awesome technology, of course, this goes without saying!)

I think lots of people had the knee-jerk reaction with respect to ads because it becomes more and more apparent on the internet that if you're not paying for a service, you are the product (been said 1000x, but oh so true), and we definitely don't want BitShares to give this impression. As you know, image (and trust) is something that takes time to build up, but can be lost really fast, and I think lots of people here would lose a lot of confidence in BitShares if ads started popping everywhere (like: that's the business model, really?).

  to most of the reactions in this thread, please oh please don't start puttings ads everywhere, this is the worst you could do... To be honest I'd rather be diluted than start seeing ads on bitsharesblocks...

Delegates that are not thinking about how to free themselves from the need of delegate pay will bring far less value to BitShares than delegates who do.

I beg to disagree, I believe core developers (like you, bytemaster) should really spend their time developing on the core code instead of trying to monetize your blog via ads or referral links. I also very much doubt you would manage to be paid enough, people reading your blog are absolutely passionate about what you write, but let's face it: you don't stand a chance even against a stupid cat video on youtube, page-views-wise.

In the end, it really is up to the shareholders to vote for who they want to see as delegates, and if they want to see a team being fully paid by the blockchain to continue developing, then so be it. If they want to fund a delegate only for a current period of time, for a bounty or a one-time job, then so be it too. As long as the delegates can convince the shareholders they bring more value than what they consume, then that's it.

Of course, it is a good idea for delegates to have a backup plan in case they are voted out, as there's no promise they will stay voted in, but I believe some do provide a core service to the blockchain and as such should be paid directly for it.

I upgraded but didnt update version

a common thing to do... (talking from experience ) I just implemented automatic version publishing in the bts_tools, I believe this should be a feature useful to quite a few people...

I just released 0.1.4, which publishes feeds for BTC, gold, silver and all fiat BitAssets. You still only see a few of one in the UI, but they are all published (you can tune which ones are shown by editing the VISIBLE_FEEDS variable https://github.com/wackou/bts_tools/blob/65bfb166d86ad55162a51e1b620e2e2848336efe/bts_tools/feeds.py#L41)

Another main feature of this release is that there is full support for building and monitoring PTS-DPOS clients:

$ bts build pts
$ bts run pts
$ bts monitor


You can also build Sparkle, although support is still experimental as there's no official release of the client yet (it does build alpha.7 correctly, though)

$ bts build sparkle
$ bts run sparkle


delegate name: btstools.digitalgaia (Standby | 7.45% votes)  (http://bitsharesblocks.com/delegates/delegate?name=btstools.digitalgaia)
pay rate: 30%
hangout: https://bitsharestalk.org/index.php?topic=12106.msg163527#msg163527
specs: 2-core xeon, 4GB RAM, 100Mb/s symmetric, location: FR (hosted at https://www.gandi.net)

seed node: seed01.digitalgaia.io:1776  (46.226.109.66:1776)
chain server: seed01.digitalgaia.io:1375  (46.226.109.66:1375)

bts_tools source code: https://github.com/wackou/bts_tools
last published version: 0.2.4  (https://pypi.python.org/pypi/bts_tools)
updates: see last posts in this thread for current updates, official changelog for released versions can be found here: https://github.com/wackou/bts_tools/blob/master/HISTORY.rst

---

Hi all,

Having learned about Protoshares about a year ago now, I have since then been fascinated by the DAC concept and BitShares in general, which is why I decided to run as delegate since the launch of BitShares (and the dry runs before that), and have been developing some tools in order to maintain my delegate easily. This has been open source since the beginning and the source code can be found here: https://github.com/wackou/bts_tools

What the tools do is that they automate a lot of the tedious tasks needed to properly maintain a delegate, such as building a new version, publishing feeds, not forgetting to update the info of your delegate with the version after an upgrade, monitoring of network connections, etc... and will send you an alert by email or iOS push notifications whenever the client crashes or starts missing blocks.

I have created a 30% paid delegate to fund my development of the tools, and further participate in the BitShares ecosystem (eg: I already provide a seed node too, but would like to provide chain nodes, write howtos about setting up a new node, etc.)


Mission

My mission is to enhance the security, stability and overall reliability of the BitShares platform, by making it easier to run a delegate properly, and enforcing good practices. I also have some ideas about making the network more resilient to defects, lack of connectivity and/or directed attacks which I would like to explore if given the opportunity.

These 2 main avenues of development can currently be seen on my delegate website:

• the bts_tools development mission: http://digitalgaia.io/btstools.html
• the network strengthening mission: http://digitalgaia.io/backbone.html

Short-term roadmap

The roadmap I plan to follow for the short term future is to go on developing the bts_tools, fix bugs and implement feature requests that can be seen in the github issues tracker: https://github.com/wackou/bts_tools/issues

Mainly, I would like the tools to be ultra-reliable (what good is a monitoring tool if it crashes?) and start implementing what is needed in order to monitor specialized nodes (eg: seed nodes, chain nodes, backbone nodes) instead of just delegate nodes.

As for network health, I also pledge to set up and maintain 2 seed nodes / chain nodes in each major geographical region (US, Europe, Asia) for a total of 6 nodes for as long as I am voted in.


Long-term roadmap

In the long term, I plan to continue maintaining the delegate tools and make it easy for delegate to perform their duties easily (by writing tutorials, etc.).

Once we know that all delegates are operating in a stable way, I would also like to try to investigate what could be done at higher level in order to ensure that the network functions properly (for instance, I firmly believe that it would be beneficial for the network if it could be ensured that it acts as a small-world network), and would like to build incentives for nodes to coordinate in order to guarantee that, or provide myself nodes that would do that.


About me

My name is Nicolas Wack, and I have been developing in C++ for the last 15 years doing mostly audio analysis (main project of fame: http://essentia.upf.edu/, source at: https://github.com/MTG/essentia) and python for the last 10 years or so, doing a bit of everything (main projects: https://github.com/wackou/guessit (active) and https://github.com/wackou/smewt (retired, for lack of time))
You can see some of my projects on my GitHub account (https://github.com/wackou), as I am a fervent believer in open source and free software as a better way of developing software.

Thats almost exactly what I want to do, just better.
So keep up the work!
I will vote for your delegates

Thanks! And don't hesitate to put bugs/feature requests in the github issues tracker