Dear BitSharians,

One more time, my pleasure is to introduce another, yet vital proposal to the BitShares stake-holders and Community. Earlier this year, we welcomed Trusty.fund (open-source portfolio management app) to the BitShares blockchain. As most of Community knows, we had some progress together and on 13th of June Trusty decided to make an important step and fly in to Thailand for a real meet and discussion about BitShares eco-system. How it went you can see on the images below:

---

---

---

Now, thing that Community doesn't understand or fully appreciate about Trusty is that

   - Trusty.fund instead of developing/fixing existing React based UI, did complete from scratch build of new library for BitShares under the Vue Framework from original https://github.com/bitshares/bitsharesjs

It was not a fork, it was a fresh new Framework and library to be used by other developers, given to the blockchain as open-source https://github.com/TrustyFund/vuex-bitshares.

This is not just a building app on existing long-lasting tools but enabling new framework to utilize bitshares and enable more developers to join the eco-system. If nothing, it should be forked to BitShares, to properly advertise Vue support we have for our technology.

WORKER DETAILS

Worker is to finally provide to the Community DEX with mixing best of UI/UX from Bitfinex and Huobi to demand of our DEX users. We aim for top-notch/bleeding edge app solution for the requirements/demands shown over the time. Wallet/DEX would be coming in 2 templates, with 2 logos of choice (BitSharesDEX or BitSharesAPP). Both wallets would be fully responsive (mobile friendly) as you can see on current demos/examples of Trusty work within proposal documents. Its a budget worker proposal, its split in 2 sprints of 3 months each, with payments every 3 weeks, improved hour tracking system/software and complete new solution for the Community.

We do believe that BitShares development community will benefit very much from adopting the two most popular JS frameworks for creating UIs: React.js for corporate demand and Vue.js for the community. Seeing development peak of both would be a brighter future for BitShares.

The price and the hours are per max budget, and on this amount of people in the team with only 4 hours available daily to devote themselves to BitShares we came up to carefully estimated max of 6 months and 300,000.00 USD. We don't expect to hit that budget, but we do appreciate more space for the bugs and actual development to ensure max quality in final delivery.

WORKER DOCUMENTATION

First 3 months ( $150,000.00 USD max. Budget ) - Part 1

http://apasia.tech/bts-workers/bitshares-communitywallet-worker-p122018.pdf

Any funds not spent/hours not claimed will be returned to Reserve Pool from the respective Escrow.

Second 3 months ( $150,000.00 USD max. Budget ) - Part 2 - Final Delivery

http://apasia.tech/bts-workers/bitshares-communitywallet-worker-p222018.pdf

Any funds not spent/hours not claimed will be returned to Reserve Pool from the respective Escrow.

NOTICE:

Worker Part 1 would be going on-chain if positive feedback is shown. Worker Part 2 is current estimate and it's expected to be changed updated after the final report of Worker Part 1. There will be no on-chain proposal regarding Part 2, until all parties are satisfied with outcome of Part 1 and Worker status is set to done/expired.

DESIGN MOCKUPS

Trusty.team has in-house designer and used its own resources to create mockup for the proposal, by in-depth analysis of popular use-cases on global scale in crypto exchange design. Mockups are as presented, theme will be available in dark/light version. Landing page is only finished for proposal and no further changes will be done on mockup, unless worker gets on-chain and voted in. Please bare in mind that how your time costs money, as per proved professionalism our time cost nothing less. We are open-minded for suggestions that will only be in the limit of UX best practices and limits through responsiveness across all mobile/tablet devices.

Respectfully, for each suggestion that stake-holders and community try to point out to us, please explain in as much as possible descriptive way in order to get proper feedback from the team.

Design preview: http://apasia.tech/bitshares-community-ui-mockup/

Design of inner pages will be ready before Part 2, and progress will start if the Part 1 gets voted in.

WORKER - OPEN POSITIONS FOR BITSHARES DEVELOPERS

In the worker documentation you will find that 3 positions are opened. We would encourage any existing/known BitShares developer fitting these positions to get paid and create a positive mix of coding arts together with us. If there is no such interest, we have our own people ready, we were just trying to make it more friendly, as we (myself, apasia.tech and trusty.team) supporters of current UI Team worker as can be confirmed from other discussions or my personal votes - i'm selected Proxy of Trusty.

1. Project Coordinator / Coordination, QA and Testing
2. HTML and CSS developer
3. Frontend JS developer

ESCROW PARTNER

We've asked initially Move Institute, but we got response that escrow is still not ready. Meanwhile, during feedback and waiting for final response from Move Institute we would like to ask that if Institute is not available BitShares Blockchain Foundation steps in. Invoices on work from Thailand will have 4% withholding VAT only for IT services.


DISCLAIMER:
In order to balance between Trusty team and any reasonable request from the stake-holders, community or potential hiring for open positions, will from now on until end of worker go directly through me. I can be PM'em here, easily found in Telegram or directly here in the thread. Armen will manage project/team, while my position is management of the worker and requests to it/final reports from it.

Feedback is welcome!

Thanks.

Dear Stefan, it seems we are very close in terms of the security approach and specific features implementation. We launched the worker as it is, but also would like to get in touch with BBF to find the best ways to deliver. If needed, we will create another worker to implement the approach that works best for all parties.

I would be supporting any contribution to a Core Team Worker with funds designed for integrations/developments as these are, and I would be giving my vote to the new worker when all steps mentioned are done and confirmed by all parties.

Quote from: yury on July 24, 2018, 08:08:26 am

The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 

Ok, so that would basically be some kind of hashing of user given values (e.g. MAC adress or IP, some kind of hardware hash etc.). Sending that information to the node (server) brings aspects of user identification and anonymity in play. Question in my head: Is there a way to tighten security without compromising identity?

I would not be supportive towards centralized server that will host all of that private information from a user/client when we don't even have basic KYC form. It's creating another security risk plus illegally compromising privacy information of individual without previous signed agreement to it. E.g. "Terms of Use" thick box with defined legal obligations and limits of the service, clearly stating which information is being obtained, how is being stored and what would happen if it gets compromised. Everything would be in a need to be legally defined, and each user has agreed to it during registration of his account, which still brings us back how we would process all accounts already created without it and as mentioned how it would affect all that anonymity hype with account creation we currently present ?

Thanks in advance for feedback and will be following up on communication progress and new worker.

Cheers

i like the idea of having more infrastructure with official worldwide nodes as proposed.

a few points to consider:
- there is no node in south america. i understand blockchain usage in general is not so popular here as other continents, still i think a node in Brazil or Argentina can bring some value.
- will you consider on hosting 1 elasticsearch node ? i think that if the wallet start using the feature we might need 1 more official node available(there is already 1 up from the BBF infrastructure worker rest is community members aka @clockwork).

price looks reasonable and APAsia already have a reputation in the community, i think it will go throw.

pd: also no node in Africa where the usage is probably even less than South America. Node in Hong Kong ?

Aflredo,

1) Elasticsearch, as proven in the past few months with help from Alex and other participants, is something really needed for the infra and probably only scalable future of it. We didn't deployed in past 2 months any ES node, as explained came to financial limits where ES node is quite demanding (re costs/system specification). Currently status200 is full node in our list and its being used by DEXBot, which could be only setup as ES from our current list.

Another thing we discussed not long ago in Telegram, I would be deploying one physical server in Thailand with raid setup of 2x1TB or SSD higher iops (Samsung EVO series) with max ram i can fit in some of intel boxes i have and one dedicated IP for the purpose of outside testing and most important - proper introduction of ES to myself. I also do believe I said I would be willing to share ssh with you, Alex, Fabian or whoever is interested to gets the most of it.

Eventually even if above attempt fails, we can remove few nodes to get available funds for ES node through this proposal.

2) Geological and logical demand for Public API such as South America or Africa is obvious - yes. On our last Steem post re infrastructure we even deployed a map with BTS pins for current infra and missing parts. So, as per your request explained:

Hong Kong - BitShares has a lot of investors, 3rd party businesses and Witnesses around China/Hong Kong that can provide such API (already OL and one more are having HK in wallet) - they can and should handle it.

Africa - We had tries in Arusha, Cape Town and private hosting, and i do have real friend in Tanzania living for nearly 10 years. Africa hosts are slow, SSD is sometimes HDD, sometimes SSD but then it starts running slow, and system specifications are very limited per choice of size. We did investment and tests on various ISP's in Africa, for 2 consecutive months, and all of them failed to provide node that even can replay normal node (not full) within some normal eta of ~6 hours with up2date blockchain database locally downloaded. So big NO to Africa for now if we want to maintain stability and reputation when it comes to uptime and availability of the nodes listed in worker. Later today when i upload invoices, there can be also found those few attempts mentioned.

Community Member and Stake-holder who is also a trader of DEX - Trizle - was the reason why we started exploring Africa. In December that man suffered a lot only because no having available API and relying on localhost that sometimes fail to sync for hours.

S. America - Brazil (Sao Paolo) is only reasonable option. There is one host worth of trying for node that would cover requirements of max-ops 100 if that SSD is real, but cost is still - we can build ES on Privex for this price, and they still have decent ping to California and other souther parts of USA.

HostDime is having 4GB node with 80GB SSD for 150$ per month. My biggest concern is that is KVM VPS and probably SWAP are locked/limited and there will be not much use for it (as we had some fails in the past). We can in case that worker goes through replace one Paris from AWS with one Sao Paolo from HostDime and together with you and maybe Diogo Gomes, test the node privately is it worth of presenting it to public.

_____________________
- I've personally tried to use best of my networking knowledge and create a pattern on the globe to utilize maximum availability. We did first (and only) public node in Australia and Canada, covered from East to West Coast of USA (where last year was only Xeldal and broken Texas node - before movement of witnesses re bitcrab vote and requirement) and all i'm saying we really had careful picks not just random purchases. I intend to keep utilizing network and optimizing its costs.
- I would point out that ES node that we would be hosting through worker has only sense having home in USA and best ISP for it would be Privex.io - Alex (Clockwork - Witness) is hosting ES in Asia and Fabian (Xeroc - BBF) is hosting ES in Europe.

Thanks for original input and feedback and hope to read more from you on this. Very important topic indeed, since we got into the problem with finance from scalability issues.

do you plan to report on usage stats?

Such as bandwidth or average/total connections/ddos attempts, etc? If yes, its built-in in both AWS and Vultr and for Sweden and Slovenia there can be done local traffic monitor. As example, one time it was posted re discussion of Public API abuse on the github (i believe england.bitshares.apasia.tech was on the screenshot).

For the uptime stats, latency and availability will be used status pages as mentioned in worker. One for all listed Public API's and one separate for just nodes listed in this worker.

When you already mentioned, maybe it would be good to make an offer:

In case that this worker gets approved/voted it would be nice as respect and support of BBF infrastructure worker, that we can wrap our nodes under their balancers, and add their balancers/nodes to separate status page (their proposal is having milestone for development, we have it using uptimerobot), to get more data from monitoring to be compared, improve bug tracking, add more transparency to the stake-holders, etc.

Personally, I do believe that such co-operation would be of great benefit for everyone.

Ladies and gents,

As many of you know, we've been running few nodes for a while (not listed in wallet most of them, but publicly shared and used through various channels). That Collaboration and Contribution will come to an end, unless we can keep those nodes and continue even more professional management through the agreement with BitShares DAC and approval of it's stake-holders through this offer as a Worker Proposal :

http://apasia.tech/bts-workers/bitshares-infra-worker-2018-APT.pdf

Worker is currently not on-chain and here is brought for initial discussion.

We will provide within 24 hours costs (invoices/receipts) that we have paid until now (~$14.800,00) as proof of contribution and ownership/existence of all nodes (even more), Premium SSL Certificates, Testing and Development servers, Current online status of servers (not bitshares api - as half of them requires an upgrade we can't finance), and whatever else is needed or requested by the stake-holders and respected proxies.


P.S. I've personally consider current Witness contribution, BBF active worker and this worker something that would greatly improved stability and performance on much greater global scale and enabled more users to join.

Thanks.

Well, thats the tricky part with Committee. They dont have to discuss nothing in public or rely on stake-holder opinion/votes, apart at the only point where those are giving them vote to become Committee. That's also a loophole in Consensus that gives Committee position that goes against transparency.

It's how it is, we can't change it, but any bitAsset should be discussed publicly before any rush decisions. We have a lot of interested party here in growing any part of BitShares blockchain, in many different aspects.

How I got updated with knowledge now, Hero's biggest problem is no high demand, no maintenance and no legal paperwork.

If this can go through as public discussion and generate some idea from it, hit it

http://docs.bitshares.org/testnet/index.html is pointing to http://testnet.bitshares.eu/ but its not working? Is there no longer a public testnet available?

docs.bitshares.org is pointing to a domain without ssl (http), while testnet MUST have ssl (https) like .eu does.

Problem: Link in outdated documentation as per disclaimer.