Ship Bagpipes M2 Delivery

[decentration]

Here we deliver the long awaited M2 integrating Ava functionality into Bagpipes. The initial idea to support the automationTime and automationPrice pallets involved some uknnown unknowns at the time.

After gaining more clarity on what the scope of the project was, we discovered that the above mentioned pallets uses the full complexity of types (Sequence, Variant, Composite, Array, Primitive, Tuple) and nesting therefore, including the use of XCM, which is the most complex composition and high depth nesting (a depth of at least 14!) of these types.

Therefore we needed to build a comprehensive pallet, method, field, auto rendering solution, containing type rendering, state storage, and submittable extrinsic codec.

This means we now support all pallets in Turing. The work required was far greater than expected, though we will aim to factor the work that was surplus to this Milestone 2, in to the next polkadot proposal.

Having said that, I personally enjoyed working on this milestone, and i am sure that it will make a valuable contribution to Ava's mission which is to supercharge Web3 automation.

[chrisli30]

@decentration could you add a link of the template built for Turing Network time automation in this PR, so I can give it a try?

[chrisli30]

The first two links on this page, https://alpha.bagpipes.io/#/pages/Ava, are irrelavent and the bottom two are borken. I think we just need links of Bigpipes template scenarios for the Ava Bagpipes Template 1 and Ava Bagpipes Template 2.

[decentration]

Ava Community Page: I can (and just did hide) the the "UI Templates". But better is to look at the Ava page as an example page, for adding any templates, descriptions, photos, links, how tos. Anything can be changed if we add a PR to change it.

[chrisli30]

This needs some description. What is this Docker used for?

[decentration]

the readme has been updated, the docker can be used to test the milestone in a self-hosted environment.

[decentration]

@chrisli30 let us know if we need to make any further changes before closing this issue? though I believe the bases have been covered! We look forward to further product development, and have plenty in store, especially in terms of turning bagpipes into DApps that anyone can build.

[chrisli30]

@decentration, regarding the new changes here is bagpipe template for [automationTime](https://alpha.bagpipes.io/#/create/?diagramData=XEtWDwnDY) in a chainTx node., the template link doesn’t run out of box. I am unable to submit the transaction to the chain, and I’m not sure how to troubleshoot the errors.

Additionally, I believe this grant’s goal is to trigger swap transactions on exchanges, as references in the wireframe, https://github.com/AvaProtocol/Grants-Program/blob/main/media/images/bagpipes/bagpipes-wireframe.jpg. We can target at swaping TUR with KSM on the MangataX app. Could you help by creating a template for executing swaps based on a timed trigger, using this code as a reference: https://github.com/AvaProtocol/xcm-demo/tree/master/src/mangata ?

Overall, the submission of this grant proposal doesn’t quite meet expectations. The end-user experience is missing, which makes it hard to review the results properly. A short 3-minute video walking through how to trigger a swap on your UI would explain things much better. For all grant submissions, we’re really looking for a step-by-step walkthrough of the application, like what’s referenced in https://github.com/AvaProtocol/Grants-Program/blob/main/docs/milestone-deliverables-guidelines.md#a-step-by-step-guide-demonstrating-how-your-code-achieves-the-milestones. That would make it much easier to understand and evaluate the project.

You’re really close to the finish line, but I think it just needs that extra effort to put together a proper tutorial or showcase.

[chrisli30]

The claim of “over-delivered” doesn’t seem accurate. We need to stay aligned with the goal of the grant, which is to trigger a swap transaction on Mangata using the automation pallet extrinsics. The claim that “we support every pallet in Turing” wasn’t part of that goal. While the schedule_xcm_task function in your template is correct, the goal is to abstract it, rather than requiring users to manually fill out every field.

I personally couldn’t fill them all out without additional programmatic assistance. Without proper abstraction, it’s difficult for users to interact with these extrinsics effectively. Since the primary goal of your product is to streamline the user experience, this template link doesn’t achieve that.

An alternative approach would be to provide a template link with pre-filled values, so the user only needs to adjust the amount and click submit. Unfortunately, this template link doesn’t meet that expectation either.

[chrisli30]

For the reasons mentioned above, a detailed demo walkthrough page is required in the 0. | Documentation section. The current documentation at https://docs.bagpipes.io/docs/nodes/chainTx is insufficient on its own.

[flipchan]

@chrisli30 you can read the AutomationTime docs are here:
https://docs.bagpipes.io/docs/scheduletransfer

Try it out here:
https://app.xcmsend.com/#/create/?diagramData=1Ti7jn5lM

Its much easier to use using the custom actions(Abstracted away), documented in the link above

[decentration]

received, as per our group chat, fixing some bugs, then producing video demo

[decentration]

Additionally, I believe this grant’s goal is to trigger swap transactions on exchanges, as references in the wireframe, https://github.com/AvaProtocol/Grants-Program/blob/main/media/images/bagpipes/bagpipes-wireframe.jpg.

Thanks for your comments!

Can i just mentioned that from my understanding your goal is not completely accurate, the goal was to enable Automate Time pallet features, which includes but not solely triggering swap transactions.

The wireframe was a rough idea. And also since the wireframe, our ongoing conversation and more understanding the known unknowns and unknown unknowns that changed because we needed to render all nested types, which was a very complex job. And now users have access to the entire chain features. And i did not request an increase in hours for this milestone.

as you can see from the wireframe it was schedule_xcmp_task, this doesnt make sense to Exchange, Chain 1 etc. It was just a mock up.

In Bagpipes, we are not abstracting at the ChainTx Node level. Bagpipes UI will be able to abstract all this. In the meantime pre-made templates can be shared, which have pre-filled fields that represent mangata etc, will share this in the video demo.

Milestone goals can be updated?

We have engaged in convo along the way in group and dm chat, I did share with you the changes of what was needed ongoing. Do you remember? and do you agree? I worry you will enforce a strict idea of what you think should be done, while not taking into account ongoing conversation and what had to be done to get where we are now!

---

We've gone majorly overtime

Currently, economically, doing this is not feasible, the hours done was in the 100s of hours above what was in this milestone, but i am doing the work out of principle and to benefit the Ava project because i want to bring to life a lot of the automation and subscription features. I did mention i will try and add this to polkadot treasury grant, but this is tentative, and i was not expecting some strict enforcement given our ongoing chats.

---

Bagpipes Separates Granularity and Abstraction.

We want to give builder users all the capability to build the business logic they want so that they can implement their own use case without the restriction or obfuscation of abstraction.

We agree, abstraction is simplicity, and that is why we will focus on it in a more principled way in Bagpipes UI builder.

Creating a whole new abstraction layer for Exchanges can be done, but not sure how it is possible in this milestone given the over time mentioned above.

• Bagpipes Builder ChainTx Node, we do not abstract anything from any chain. All features are available and not obfuscated. Abstracting everything for every chain is not feasible at this layer. That is not our design approach a this layer.

The Chain Tx Node will be able to receive Pill variables, which allows for Dapp building not just as an end-user interface. The builder is not designed for end user, its designed for building logic that is middleware for a frontend.

• Bagpipes UI builder: we will enable builders to create UI with abstraction that makes sense to them

---

The work done in this milestone was something that was shared with you ongoing, thats why i believe the grant goal you mentioned is not completely accurate.

I totally understand what you want, and i would love to share with you how that will be enabled with Bagpipes.

[decentration]

Hey @chrisli30. AYK the mangata swap is blocked from the Mangata side, so the transaction will not be executed successfully.

However, what we can do is have this bagpipes template ready for when the "Scheduled Swap" tx is executed. And in the meantime, we have the MVP, which is:

1. support for all Turing pallets (ChainTX node) done by @decentration
2. support for delayed transfers using the AutomationTime pallet, which is abstracted, done by @flipchan (docs for schedule transfer)

Also, i have made the required PR to mangata to speed the swap feature along. Hope that helps! : )

[chrisli30]

Ramsey @decentration , there seems to be too much focus on "over-delivering" by implementing all pallets—something we weren’t initially aware of and wouldn’t have agreed to. Those functions have been well implemented by https://polkadot.js.org/apps/ and it does not make sense for us to pursue another similar interface. What we actually need is cross-chain swap functionality on Mangata DEX or asset transfer on Shiden or Moonriver, as intially documented in #7 . Unfortunately, that functionality wasn’t achieved yet, and this has made it challenging to continue with the project as it stands. From my perspective, the project has significantly diverged from the original goals and doesn’t align with the intent of the Turing Network grant. The objectives are documented in #7, and this delivery PR doesn’t align with the original grant approval PR.

While I remain committed to fulfilling our side of the agreement, it feels like we’re now paying for something that doesn’t meet our requirements. If you have user feedback to indicate otherwise, I’m open to reviewing it. However, as it stands, we’ve invested considerable effort, but the project hasn’t simplified user interactions—if anything, the incomplete state of the UI has made interactions even more challenging than on https://polkadot.js.org/apps/.

We’re currently building an automation UI on Ethereum, and you’re welcome to check it out after launch in three weeks if you’d like to compare approaches.

Grant approval PR for reference: https://github.com/AvaProtocol/Grants-Program/blob/main/applications/bagpipes_integration.md

This PR is approved and concluded. Initially, we set the projected token price at $0.22/AP at launch. The outstanding payment of $23,000 will be paid out after the AP token is listed on an exchange. At the projected value of $0.22/AP, your team will receive 104,545.5 AP tokens immediately after listing, fully unlocked.

[decentration]

Thanks for your response, @chrisli30... it must be annoying to hear someone telling you they have "over-delivered" when you have received something that wasn't what you expected! And from our pov, its a bit unfortunate that you havent properly acknowledged what we've worked on fully. Let's put this down to miscommunication.

In defence of our position and some objective corrections:

the project has significantly diverged from the original goals

We did inform you (in telegram personal and group chats) that we were going to support the automationTime pallet in its entirety, and in doing so this would extend to support for all pallets. You did agree both implicitly and tacitly. With the dynamic process of development, it is important to consider all ongoing communication, not just the initial goal. And given you are the only decision maker, we believe this to be a clear green light. I do believe you havent factored this in and his left us feeling a bit "gaslit", we will put this down to our imperfect communication, and i think its a lot to do with you forgetting our ongoing chats.

What we actually need is cross-chain swap functionality on Mangata DEX or asset transfer on Shiden or Moonriver. Unfortunately, that functionality wasn’t achieved yet...

Actually, both asset transfer and cross-chain swap is achieved.

• asset transfer for moonriver is achieved, in the abstraction (which is V0 Bagpipes Builder).
• And scheduled swaps as a template in our non-abstracted granular Chain Node (V1 Bagpipes Builder). although currently your desire for cross-chain scheduled swaps is blocked by mangata, and can only be supported when they update their Proxy Types. ( I made a PR on your behalf. ) Though this is a Chain to Chain issue that is your responsibility, not ours.

I have created the [Templates for the above in the Ava page ](https://xcmsend-fr7h2tck4-bagpipes.vercel.app/#/pages/Ava) to make it easy for users to get started with both actions.

---

Bagpipes Phillosophy
It's also worth noting that based on feedback, we are moving our abstractions to the Bagpipes UI Designer. The UI Designer will add an interface to the Bagpipes Builder workflows. The UI Designer essentially is the abstraction you are looking for, and it is for the end users of the builders who use the Bagpipes Builder.

We decided to follow the granular philosophy, not hiding functionality from builders in the Bagpipes Builder, thus empowering those builders with more capability and to build powerful workflows.

If you disagree with this philosophy then thats a matter of opinion, and neither is really wrong. Which is why we support Granular for the Workflow Builders, and abstracted for the UI Designers

When the UI Builder is ready i will continue to create all the templates you desire: swaps, take-profit, stop-loss, automated compounding, and all the wonderful features that can be made with the automation time pallet.

---

All pallets and automationPrice pallet
It also worth noting that with our (disputed )over-delivery, it also support your automationPrice pallet. So when this pallet is active again it will be automatically supported. And i will make some more templates of all the use cases that this pallet enables.

---

A lot of this comes down to trade-offs (simplicity vs flexibility), and we stand by our decision in what we did. Though we should have gotten you to more actively support the changes with updates to the original application so there was less chance of misunderstanding.

---

It's a shame to hear you are sunsetting the Turing chain, but i do hope you launch again soon on Polkadot, because while this is still bear market time where there is high inactivity, keeping focussed on building in a principled way will pay off.

---

Thank you for approving the PR. We of course accept your proposal to delay payment until all in Ava tokens (instead of USD and AVA) after launch at the reasonable terms you have presented.

Cheers ✌️