BITSHARES DEX THAILAND – FULL RPC NODE

JOURNEY - FROM BABY STEPS TO FULL MARATHON
IN 8 DAYS

wss://bitshares.apasia.tech/ws

---

• Connection to cli_wallet works as expected. Although due to a bug, the node can’t be added to the Access section under Settings in the UI. This is currently undergoing fix at Bitshares network.

Realizing the bug was down to the UI, thanks go out to @billbutler

Full RPC Node - If you refer to our previous post you will know that building this RPC node was a major step in @APAsia.tech’s commitments on the Bitshares DEX Thailand. We can now replicate and start moving on to set up a witness node. We arrived after a lot of experimental R&D, test node builds, trying out server configurations, searching steemit dev and witness posts for tips and tricks… not to mention swearing and hitting things, and poring over details in the extensive official documentation which comparing to the Official Github, is very different and outdated.

---

SSL/TLS – deceptively simple, hard to implement This final piece of the puzzle was implemented last night. Thus ensuring the node can be accepted and secured for public use. Another sleepless night for @murda-ra, as we [@apasia.tech] are never ones for taking the short easy way. You could say, we take the path to the highest quality of least resistance. At the end of the day, actions are louder than words!

---

Difference from the standard SSL tutorial - To make our node public, we did not follow the suggested ‘Let’s Encrypt’ free SSL. Not that there is anything wrong with it for setting up your own node. However, we wanted to ensure the best security and performance possible, and every component is selected to reflect this. A dedicated Positive SSL certificate was thus purchased and applied to the node domain, through NGINX ( https://bitshares.apasia.tech )

---

Node Latency Whilst in the telegram chat, when we discovered the earlier mentioned UI bug, we were also able to capture some ping stats from the other side of the world, which was actually our main concern! Why ? Thailand has limitations in IDCs over Bangkok, for majority of the clients, where international bandwidth is very limited (similar concept to close network in China). Even though, one more time @billbutler

---

**HEADACHE OF BEING SYS ADMIN** - As the CTO of @apasia.tech, @murda-ra isn’t one to easily give up. Like any top-level experienced professional, a help request is never going to be a case of RTFM. However, the point is a big thanks to all the community for pitching in help during our ‘darkest hours’.

---

Conclusion and Next steps

---

• Finally, there has been a lot learned, with us coming to know the community better, we are also starting to see some directions in which Bitshares can take to grow and prosper together. In that respect, it is very possible we need to contribute and polish some worker proposals with the community. Before @apasia.tech does anything with BitShares, we also need to reflect on the quality statement made earlier. The foundations need to be strong before more companies build on top of the blockchain. BitShares is without a doubt the best platform. But some of the essentials need to be polished. As such, the to-do list that came up as wanting starts something like the following;

Bitshares Improvements/Fixes Proposal List - TO BE CONTINUED

1. Documentation
2. Official Pages/SEO/Content/URLs/rDNS
3. Bitshares UI (Exchange Frontend) - From top to bottom (BUGS, Gateways, Buttons, Functionality, UI/UX, Mobile version css improvements, Browser Compatibility, zendesk online support)
   3a) Bitshares official website (For progress click here – thanks to @richcg )
4. Gateways
5. Monthly inspection on witness nodes and latencies (failed to broadcast transaction because witness signed the block but stuck in the process delivering transaction due to high latency)
6. Reconfiguration of all nodes (RPC, Witnesses, Workers, etc) Nodes shouldn’t be run from DOCKER as it drains more resources by just running it. Ideally what is needed is a documented procedure for a MANUAL BUILD from SOURCE ¬–since there is no better way to handle and manage it as a service.
7. Unique ticketing system for all UI instances running on top of the blockchain with possibility to divide UI’s into groups and Agents to corresponding groups, with few main administrators who can overview all. In that case entire community would be sorting out tickets and helping out across the globe with a unique database of all issues ever happened though user interaction with blockchain/UI. Certain business entities that want complete privacy can have it via white-labeled support, but still sharing same SQL with the rest of the network, so official blockchain admins would be having both instant and history access to issues users submitted. Also it would be very nice and easy way of presenting support performance stats, for each member of Bitshares community running its own UI, so the Bitshares itself can protect himself from 3rd parties trying to break the core of the community by being unskilled or not business pro-efficient.

Point (7) would be most easy to build, but hardest to implement due to current status and disputes of the internal community of blockchain.

---

Upcoming - The above will be covered in future posts, as well as being discussed earlier in the Telegram channel. Next step – Docs and post on how to build an RPC node, and we have investment budget planned for development and gateways, plus one more node for witness due by the 21st December. Furthermore, the official Bitshares UI with addition of Thailand underneath.

Thanks for your support and we welcome all comments below – We still have a lot to do and focus towards improvements of the Bitshares Community! For those of a more technical leaning, look out for @murda-ra’s upcoming post/tutorial about the entire build.