Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - R

Pages: 1 ... 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 ... 68
556
Stakeholder Proposals / Re: [Worker Proposal] Bitshares UI Renewal
« on: August 15, 2018, 08:46:54 am »
Sadly, I must agree with Kim becuase unlike customminer I am not in the inner circle, so my bug ID and bugfix contributions to the repo are derided, my bounties reduced, and I have been openly called a dick by the project manager here for simple discussion.

My words, my time, on github issues has been fully erased. Really, really unlike any other open source repo on earth.

Can you provide examples of your issues being fully erased? AFAIK it's impossible to outright delete issues - they can only be closed (https://stackoverflow.com/questions/3081521/how-to-completely-remove-an-issue-from-github). I don't see any rejected/closed pull requests in the last few months neither?

What's your github username on the repo so that I can see what you're talking about?

557
I think this is a problem that price feed scripts should address, rather than proposing to somehow change from median(price feeds) to max(price feeds) within the bitshares core.

If price feed publisher's scripts are overly reliant on BTC:BTS prices then they should be upgraded to sample multiple exchanges, accounting for trading volume (flagging suspected centralized manipulation) and sampling from many more alternative trading pairs such as USDT, ETH, mutliple internal bitshares market references (feed|market)..

With Max, if a single price feed publisher publishes 1000000 (or some other very high feed) then it would cause global settlement, where as median price feed would have been more secure from such an outlier price feed.

558
Stakeholder Proposals / Re: [Worker Proposal] Bitshares UI Renewal
« on: August 10, 2018, 10:12:58 am »
You just need to ask the community how they feel about the progress made thus far and you will quickly learn how disappointed people are. They are expecting UI/UX changes to be made that allow the wallet to be easier to use which will lead to greater adoption. Instead we get a bunch of resolved bugs, but very few design changes that offer a better user experience.

People really need to do more research on the contents of worker proposals then before they vote perhaps? Big new exchange redesigns and user studies are great, but maintenance of the current released codebase is highly important & it's not a task covered by either of the new Bitshares exchange redesign workers which push their own maintenance off to future worker proposals.

I know the reference wallet is supposed to present all features offered, but why not bring back a well designed "Easy" wallet version?

There is the 'basic' web view mode, and there are several android wallets with simple interfaces, if you don't think such work is out of scope of this worker proposal, then why not raise an issue on bitshares-ui requesting such a feature and perhaps offer to complete the bounty yourself?

I've recently discovered that they lacked designers and developers which explains why certain things fell off the table, but the lack of transparency only made our negative perception that much worse. Let's see what Startail and his team can do during the coming months.
I don't think it's fair to claim there's a lack of transparency - what do you specifically refer to? I find the operation of bitshares-ui repo maintenance by this worker proposal highly transparent & the workers easily contactable. If you go on the bitshares-ui github repo then you can see everything this worker is doing, check the issues, commits, branches, pull-requests and the project boards to see what's happening & if an issue you're interested in has no traction then voice such concerns in the issue.

Your exchange redesign concerns/criticisms would be most appropriately voiced in the following bitshares-ui exchange redesign github issue: https://github.com/bitshares/bitshares-ui/issues/1477

559
This worker proposal looks great, but I hope this worker and the bitshares-ui worker proposal teams can collaborate rather than duplicate work efforts?

560
I like the effort to implement the UI using an alternative to ReactJS, however could you elaborate on the final product? Will it result in a stand-alone client or a web wallet? Will there be a maintenance period after its completion, or would this require an additional worker proposal?

Do you think once this is completed that it'd be wise to investigate additional alternative frameworks than react/vue? An implementation of BTS for all the major frameworks?

---

Probably off topic, but a cool idea would be a UI toolkit for integrating the entire BTS DEX into CEX websites, rather than limiting themselves to single tokens they could offer direct access to the BTS DEX. Probably not realistic though?  :-\

---

The only thing that has me apprehensive about delivery is that the bitshares web page still has not changed despite being transfered ownership a few months ago?

561
Stakeholder Proposals / Re: [Worker Proposal] Bitshares UI Renewal
« on: August 04, 2018, 11:27:18 am »
I fully support this worker proposal, it's highly productive and allows for community oriented bounty claims.

@kimchi-king - I don't get how you can claim this is misspent money nor how you've failed to noticed any of the changes that this worker has brought to the reference wallet implementation. I've easily had 10+ of my own issues addressed and resolved via the bitshares-ui repo/worker in the last year, plus the UI has undergone large changes (see tradingview charts, ant design, increased responsiveness/efficiency, new modal pop-up modules, etc).

---

If I were to provide one suggestion for improvement, it'd be that bug reporters aught to get a very small % of issue bounty reward, for bringing an issue to the table that was worthy of implementation. It'd attract functional testers and encourage more users to report their annoyances with the UI if they knew they'd get a couple bucks for their time writing up the issue.

562
I really like the idea! It's better to deal with security head on, rather than letting it bite us in the rear!

I've got a couple ideas which I hope will warrant a tiny bounty.. hope the worker gets activated!  :D

563
RE design audit:

Quote
List with all main indicators
Main tools for drawing on chart
Chart view setting (colors, sizes)

Already implemented recently using tradingview, please tick these for the Bitshares column.

Quote
Landing page

I believe another team has full control of this and plans to implement a new design - out of scope for this worker proposal, IMO.

Quote
Exchange:
The trading layout is hard to customize and fails to take into account traders’ personal preferences
The variety of drawing tools on the chart is insufficient for advanced users and on the whole not visible enough.
The number of indicators is too limited for experienced users.
Chart settings are not clearly visible or easy to find.

False - tradingview changed the above weeks ago.

Quote
There is no indication of progress during the transfer of funds to the exchange
This would be the responsibility of the gateway service, unless it was some sort of atomic cross chain transfer.


564
Could you please include all MPA, not just committee owned smartcoins?

Website looks great! :)

565
Should we require asset owner permission to use said asset as backing collateral for an MPA?

Recently, issue #1537 in the bitshares-ui Github repo highlighted the fact that despite the UI and documentation indicating that UIA cannot be used to back an MPA on the BTS DEX, the reality actually is that UIA are an allowed backing collateral asset type in the core code.

This BSIP is not arguing for/against UIA being used as an MPA's backing collateral, because this is already enforced by core (Abit has a testnet asset configured as such).

The purpose of this BSIP discussion is to decide whether or not you should require owner permissions/approval of the asset being assigned as backing collateral for a new MPA.

---

Why I think we should require permission

  • Any assets locked away as MPA backing collateral cannot be reclaimed/recalled by the UIA owner (even by force). This has the consequence of being unable to reduce the supply to 0, potentially preventing asset settings from being changed or the asset from being fully shutdown.
  • By 'wrapping' an UIA in an MPA 'container' the MPA owner can effectively impose new asset settings over the existing UIA flags/permissions/settings to the potential detriment of the UIA owner.

Why perhaps we shouldn't require such permissions


  • An asset owner may refuse (or be unable to) provide permission to use the asset as backing collateral, requiring an alternative asset for backing collateral.
  • The committee may be overwhelmed with requests to use committee owned assets as backing collateral, though that's subjective.
  • The committee would have a greater centralized control of backing collateral selection on the BTS DEX, however that could result in more private MPAs being created. The committee size could be increased too to offset risk.
  • Existing MPA with non-BTS backing collateral may make implementing such a permission requirement too complex? Perhaps existing MPA could be exempt?
  • What if the asset owner removed their approval at a later date? It'd have to be permanent approval unless supply was 0.
  • What happens if you have owner permissions of the backing asset & MPA, then transferred the backing asset ownership to another account?
  • Being able to avoid market fees and replace restrictive permission flags with an MPA is pretty cool.

Exclusions: The Bitshares core token (BTS) should be excluded, as nobody has ownership permissions over it.

Github link: https://github.com/bitshares/bsips/issues/80

---

What are your thoughts?

Can you think of any reasons for/against requiring permission to use an asset as backing collateral for an MPA?

566
Excellent work, thanks for the 64bit build ;D

567
So what, is this an UIA/MPA issued on the BTS DEX, or a new graphene chain? If the later, any sharedrop planned?

568
Stakeholder Proposals / Re: proposal to create bitXCD
« on: April 25, 2018, 09:49:09 pm »
so... any news on bitxcd?
It's operational, however no news regarding its adoption yet, it has far greater collateral than that which the FIAT XCD issuers provide so that's got to be appealing..

569
I am going to push two proposals:

1\ Set up a bounty in the whole community, to improve the API capability of a single node. The best improvement win the prize,and the code can be merged into the mainnet.

2\ Improve the voting system by adding decay factor for voting. For example, the votes will expire unless updating their votes every month/year...

Anyway, the above is just simple thought, more details will be added gradually, and welcome any kind of discussion.
1 not covered already by the bitshares-core worker?

2 related to the following BSIP? https://raw.githubusercontent.com/bitshares/bsips/master/bsip-0022.md

Pages: 1 ... 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 ... 68