Hello Radicles! 
This bi-weekly comes a little bit late as we were busy speaking at EthCC in Paris last week! Our talk was ‘Towards peer-to-peer code collaboration’ — it discussed why we’re building radicle and why.
If you’d like to watch the full video you can find it here. If you don’t have 47 min, this twitter thread has the highlights.
@coco:
-
The issue tracker has spurred some WIP and discussions:
-
A first draft of networking that is functional. Kim is going to give a run down of the code internally.
@application:
-
We at last embarked on our first big feature deliverable
Identities 1, check the milestone for a comprehensive overview. Our main focus is to translate the most critical flows into UI code. As per usual, our focus is on getting consensus on the boundaries and API surfaces, which lead us to first implement mocks that the UI could be written against. In the process we discovered that the Registry doesn’t have the resources to support the newly discovered changes to users. Users, just like Orgs, will be allowed to have projects now — much like platforms like Github/Gitlab. In order to not build unnecessary fake behaviour into our Application proxy we decided to contribute to and drive the Users implementation in the Registry.- Mock changes: Implement Basic User Identity mocks by xla · Pull Request #199 · radicle-dev/radicle-upstream · GitHub
- New Identity flow: https://github.com/radicle-dev/radicle-upstream/pull/211
- User handle registration flow: User handle registration flow by MeBrei · Pull Request #216 · radicle-dev/radicle-upstream · GitHub
- Tracking meta issue: User registration · Issue #202 · radicle-dev/radicle-upstream · GitHub
- Upstream issue for user registry: Integrate Registry user registration · Issue #185 · radicle-dev/radicle-upstream · GitHub
- Tracking issue on Registry: Implement users registry · Issue #245 · radicle-dev/radicle-registry · GitHub
- Precursor to the planned changes: Adjust OrgId and ProjectName to new required validations · Issue #239 · radicle-dev/radicle-registry · GitHub
-
As per usual we did not simply dive head first into the feature changes, but addressed some improvements to be done in order to enable smooth implementations. These were mostly around extracting and improving common components, with some quality of life improvements along the way.
-
Special shoutout to @cloudhead for contributing to the org and identity avatar generation in the most imaginative way: https://github.com/radicle-dev/radicle-upstream/pull/217
-
Product work on issues feature design has started !
@registry:
- We have been working on implementing transaction fees in our blockchain, the Radicle Registry. We came to realize that for transactions that involve organizations, the fee should be paid by the organization itself. This requires us to have control over who pays the transaction fee. To achieve that, we have been exploring how to implement our custom transaction fees on top of
Substrate(where the tx author is always the one paying for transaction fees). Having the organization pay for the fees introduces security concerns. The author of the transactions must be authorized to issue such transactions that impact the funds of an org. Currently, in a pre-dispatch phase, we must validate the transaction author to have enough funds to cover the fees. This prevents malicious authors from spamming the network with high bids on transactions. These will be prioritized but not materialized, resulting in neither paying for the tip.
That’s all for this cycle! See you in two weeks.
Best,
Abbey