New api primitives

[aulneau]

What's your name/your team's name?

Hi! We are Thomas Osmonson and Jasper Jansz and our team is Fungible Systems.

Best email on which to contact you?

• thomas@fungible.systems
• jasper@fungible.systems

Personal Statement

We have worked in the Stacks ecosystem since 2017 and 2019. During this time we've worked on and built some of the ecosystem's most prominent products, such as the Hiro wallet, Stacks Explorer, the Stacks docs, the stacks.co website, stacking.club, and many others. While stacking.club is already the home of the most up-to-date and detailed information around stacking and Proof-of-Transfer, we believe it can do much more.

We want to dedicate our time to making stacking.club a better home for all things stacking. Currently it's a great diagnostic tool, but it can become the place where everyone goes to stack, pool, and learn. There is no one true place where someone can go to learn about stacking and then actually do it — we think stacking.club can be that place and really advance the experience of stacking.

End Product

Throughout the residency, we'll make many improvements to the experience of stacking:

• Enabling people to pool (and potentially stack independently) directly on stacking.club
• Streamlining the pooling user experience
• Making the stacking and pooling data we have easier to understand and more actionable
• Personalizing stacking data (e.g. your own dashboard if you connect your wallet)
• Exploring how we can minimize the trust involved with pooling in collaboration with pool operators
• A general revamp of the UI

Roadmap

NB: These phases are pretty flexible and not in the exact order in which they may occur.

Phase I:

• A complete redesign and improvement to the UI / UX
• Improved learning materials

Phase II:

• Stacks authentication integration (via the web wallet)
• Improved user dashboards
• Improved user-specific data

Phase III:

• Pool data exploration and comparison
• Delegated stacking (pool participation) from within the web app

Phase IV:

• Trustless pool research and development

Appendix stacking.club has been a passion project of Thomas, with him working on it during the nights/weekend while working at Hiro PBC. stacking.club will be a part of Fungible Systems, a product studio the two of us have co-founded recently since leaving Hiro PBC.

[jennymith]

Hey Thomas & Jasper, thanks for applying to be Stacks Residents. The Foundation team is currently reviewing your application in more depth and will be getting back to you about next steps soon.

[jennymith]

Hi @aulneau, looking forward to learning more about your proposal!

[jennymith]

For all community members interested in keeping up with Fungible Systems's residency, check out their upcoming plans and follow this thread for weekly updates from @aulneau and @jasperjansz themselves:

Scope of Work

Background

We have worked in the Stacks ecosystem since 2017 and 2019. During this time we've worked on and built some of the ecosystem's most prominent products, such as the Hiro wallet, Stacks Explorer, the Stacks docs, the stacks.co website, stacking.club, and many others. While stacking.club is already the home of the most up-to-date and detailed information around stacking and Proof-of-Transfer, we believe it can do much more.

We want to dedicate our time to making stacking.club a better home for all things stacking. Currently it's a great diagnostic tool, but it can become the place where everyone goes to stack, pool, and learn. There is no one true place where someone can go to learn about stacking and then actually do it — we think stacking.club can be that place and really advance the experience of stacking.

End Product

Throughout the residency, we'll make many improvements to the experience of stacking:

• Enabling people to pool (and potentially stack independently) directly on stacking.club
• Streamlining the pooling user experience
• Making the stacking and pooling data we have easier to understand and more actionable
• Personalizing stacking data (e.g. your own dashboard if you connect your wallet)
• Exploring how we can minimize the trust involved with pooling in collaboration with pool operators
• A general revamp of the UI

Roadmap

NB: These phases are pretty flexible and not in the exact order in which they may occur.

Phase I:

• A complete redesign and improvement to the UI / UX
• Improved learning materials

Phase II:

• Stacks authentication integration (via the web wallet)
• Improved user dashboards
• Improved user-specific data

Phase III:

• Pool data exploration and comparison
• Delegated stacking (pool participation) from within the web app

Phase IV:

• Trustless pool research and development

[aulneau]

Hi everyone!

We wanted to provide an update: we've pivoted away from working directly on stacking.club, and instead are moving upstream to work on API architecture and making it more accessible.

In all the projects I've worked on, I've needed to build a bespoke api instance that consumes data from something like the Hiro API. This works and is pretty effective when you do it once, and if the dependencies don't change over time. However, most projects aren't like that, and things do change. I've found that I've needed to re-implement the same patterns over and over again: fetch some transactions that pertain to a certain set of contracts, push them to my own database, define relationships, and create new queries. This can apply to any application on stacks.

At a high level, this is the way that the current dominant api architecture works:

• the api has an event observer which watches for events from a stacks-node instance
• the event observer pushes these events into a postgres database
• the api also handles reorgs (when a new block comes in that references a previously non-canonical chain)
• outside of watching events, the api has a bunch of code that runs to expose that postgres database as a REST api

Our new direction is all around finding ways to break apart the elements needed to create APIs or specific views of data related to activity on the stacks blockchain. This involves:

• Research on how current APIs handle this (namely the Hiro api)
• Research on how other projects in different ecosystems handle this (the graph, etc)
• R&D on alternative event observer architecture
• Finding ways to reduce the reliance on needing to run a node
• Exploration on how to easily and quickly expose extremely customized views of data

Some deliverables we're thinking about:

• a standalone event observer anyone can run next to a stacks-node
• an events processor that would transform raw events into usable data
• a Proof of concept implementation of both the API and an application using it (such as an explorer)

With this new direction, we are also realizing we are blocked on human resources. We are very interested in bringing 1-2 more folks as residents to help out with this endeavor. We're specifically looking for someone who leans more towards UI engineering, and someone with lots of database/back end/full stack experience.

Thanks everyone! happy to answer any questions you might have.

Thomas & Jasper

cc @will-at-stacks

[will-corcoran]

@aulneau just noting here for your records that this addendum to your residency has been approved. Please work with Shakti to get the necessary documents and payments processed.

[cuevasm]

Hugely supportive of the move, makes sense on all fronts to me. Y'all have been crushing it all around, so very excited to see your scope expand 🙏

[aulneau]

hey all -- here is an update on our work -> https://twitter.com/aulneau_/status/1530208117811814400