Element Package Repository

đź’¸ Grants đź‘‹ New Grant Applications
1

Radworks Grant Application

  • Project Name: Element Package Repository
  • Team Name: Cloudouble Pty Ltd
  • Payment Address: 0x80A29410CdDCb7E1B6469042C1CDD04fec02fc9b
  • Category: Radicle Adoption

Project Overview :page_facing_up:

Overview

The project that is the focus of this grant is the Element Package Repository - which will allow developers to publish and share their Element packages to the community.

Element is a general purpose web development framework - currently in stable beta release, designed from the ground up to be equally effective for traditional web apps, web3 dapps and local-first apps. It features the ability to extend its capabilities via simple URL-based package and component importing directly in the browser at runtime - hence the use-case for the Element Package Repository.

You can learn more about Element at https://elementhtml.dev, including benchmarks against existing frameworks, and the Roadmap.

The benefits to Radicle are twofold:

  • the user base for Radicle and Element largely overlap, so prominent and permanent branding/sponsorship on the Repository will let new developers know about Radicle
  • Element will encourage package publishers to utilize the Drips Network to collect funding for their package. This will help to ensure that Element is able to grow and thrive in the long term, and also to assist in ensuring that packages themselves are well-maintained by their authors. This will be the default way to gain a listing on the Repository, and thus every developer who thinks about listing a package, will at least consider using Drips to help fund it.

The above arrangements can be mutually beneficial to both Radicle and Element, as and the Element community grows, so too will the awareness of Radicle and usage of Drips.

Overview of Element Repository Features

A “package” in Element is a regular Javascript module in a specific format that is available from any URL - ideally via a IPFS CID-based link. It is loaded into the web application before Element launches and is used to set application-wide configuration, import schemas for data validation, define custom components, extend the core framework with custom helper functions, and more. Multiple packages can be loaded into an Element application and are layered over each over to create highly composable environments to jump-start applications.

The Repository will enable application developers to search for packages and view each package’s name, description, author link, support link, tags and mostly importantly a IPFS link to the package’s module to include in the application which will use the package. The use of IPFS links (only) in the Repository will allow developers to have confidence against package-hijacking due the intrinsic content-hashing of IPFS links.

At the other end of the process, developers will be able to publish their own built packages to the repository by any of the following methods:

  1. For packages that are potentially seeking open-source style support/funding: claim their project on Drips and add Element as dependency with a minimum 20% split to Element - this will be the default listing process
  2. For package authors who can not use cryptocurrencies: they can create a Collective on Open Collective with the package details including a link to the code and set Cloudouble as their Fiscal Host to activate their listing
  3. For packages that are not seeking their own funding or who will charge out-of-band in some way - aka “private” packages: publishing their package to IPFS and then sharing the IPFS link with the Repository via a ETH smart contract (similar to minting it as an NFT).

All three of these methods will provide an endpoint for a server-side automated process to pick up new listings, verify their code, and add them to the Repository. By monitoring these endpoints, inactive listings can be similarly garbage-collected.

For all methods the server-side process will (re-)upload the package to IPFS (probably via the NFTStorage API) to ensure permanent availability of the IPFS links. The issue of version control and a process for supporting it will have to be considered as part of the detailed planning process.

Team :busts_in_silhouette:

Team members

  • Name of team leader: David Pitman
  • Names of team members: at this point it is just me

Contact

Legal Structure

  • Registered Address: Fortitude Valley QLD 4006 Australia
  • Registered Legal Entity: Cloudouble Pty Ltd

Team’s experience

David has been a full-stack developer for 20 years. The Element framework has been in progress since 2020 in various forms, and in its current form and mission since early 2023. He has worked full-time without financial compensation on Element since mid-2023. If you want to know if he’s any good at his job, see the benchmarks for Element mentioned above.

In accordance with the before-mentioned Element Roadmap several grants are being currently applied for to assist with the completion of the Element ecosystem, but no others for the Package Repository. Once sufficient funding from grants comes in, other staff/contractors will be hired to assist in the timely completion of the various roadmap milestones, with David hoping to step back from the coding coalface a little and focus on co-ordination, overall direction and quality control. In the interests of getting things done quickly, it is not intended to open development to general community until a stable production-ready version of Element is released (target late 2024).

Team Code Repos

Team LinkedIn Profiles (if available)

Project Description :page_facing_up:

I am applying for this grant because I see a good fit between the long-term goals of both Radicle, Drips, and Element. I also see that specific sponsorship of the Package Repository is a perfect moment for the future Element community to become aware of both Radicle and Drips.

Otherwise, while 2023 was dedicated to creating a working beta release of Element, 2024 will be for creating the complete, production-ready ecosystem ready for growth in 2025 and beyond. Thus far, the project has had no external funding and the on-ramp is about used up. Other grant applications are currently in-process for other parts of the roadmap (namely, the initial stages of the Documentation and Dev Tools milestones).

Deliverables :nut_and_bolt:

  • Total Estimated Duration: 10 weeks
  • Full-time equivalent (FTE): 50 days
  • Total Costs: 25,000 USD

Architecture Design And Research

  • Estimated Duration: 2 weeks
  • FTE: 10 days
  • Costs: 5,000 USD
Number Deliverable Specification
1. Detailed Process Schematic A detailed and thoroughly researched schematic outline of how the various processes of the Repository will work together. Including also which services will be used to provide the required functionality.
2. API Specification A detailed specification of the server-side REST API and scheduled functions that will be used to provide the required functionality.

Smart Contract

  • Estimated Duration: 2 weeks
  • FTE: 10 days
  • Costs: 5,000 USD
Number Deliverable Specification
1. ETH Smart Contract Development and deployment of smart contract for the “private” listings feature

Prototype API

  • Estimated Duration: 2 weeks
  • FTE: 10 days
  • Costs: 5,000 USD
Number Deliverable Specification
1. MVP API Prototype working build of the API built on Deno for quick iteration and convenience.

Front-end UI

  • Estimated Duration: 2 weeks
  • FTE: 10 days
  • Costs: 5,000 USD
Number Deliverable Specification
1. Front-end UI Make UI available from main Element website

MVP Launch

  • Estimated Duration: 2 weeks
  • FTE: 10 days
  • Costs: 5,000 USD
Number Deliverable Specification
1. Testing End to end testing of required MVP features
2. MVP Launch MVP product launch
3. MVP Review MVP review and compilation of improvements, changes and additional features required for a completed, mature product to be developed in the future second stage of Repository development

Future Plans

The concept of package and component importing via URL is deeply baked into Element, and it is anticipated the initial developer outreach will focus not only on the benefits, but also on the opportunities it present to early adopters in the future Element ecosystem to create key components and packages that will become widely used. Thus, the Package Repository will be a key part of the Element ecosystem.

By taking a listing / platform fee to be applied to Element’s general funding pool, over it time it is hoped that the Repository itself will provide sufficient funding to allow Element to remain continually updated and at the leading edge of what is possible.

This application covers only the first half of the Package Repository’s complete development. Once this MVP product has been achieved and deployed, further funding requirements will be reviewed and if necessary will be sought from the best matched source(s) at that time.

For example, this initial MVP stage will be powered by the an API built on Deno with repository metadata stored on Deno KV. This is not ideal as it requires a centralized hosting service. The second stage of this project will have the primary goal to re-deploy the API onto a decentralized service - the current leading candidate being as an autonomous and self-funding SNS on Internet Computer. If this is chosen, one possible funding source for the second stage will be the Dfinity Developer Grants program.

Additional Information :heavy_plus_sign:

How did you hear about the Grants Program? Originally by Google Searching, but that was a while back now - have been silently following Radicle in general for a few months now

2

Making an important change to the architecture:

The three options for publishing/funding packages will be coalesced into a single system based on Drips, with an integration with a fiat on/off ramp. I still have some more research to do on this, but I think I have established that it is both possible and optimal, and will have a prototype up and running in the coming days.

So basically the Repository will use Drips as its core payment system, it is perfectly fit for purpose.

3

Hi @drpitman

Thanks for this.

Element sounds really promising. The benchmarks you’ve put it through are really impressive.

As you’ll see from our Grants 2024 plans here, we are focused on building with our protocols (Radicle or Drips).

My initial thoughts on this are:

I don’t see a tight coupling between this work and building on either of our protocols (Radicle or Drips).

This work seems very specific to Element, which makes it narrow in scope. The big assumption underlying a lot of this is that Element will be adopted and have a large user base (based on the benchmarks, this doesn’t seem unreasonable!). But until that happens, is there a broader problem we could solve? e.g. rather than pushing Element, could we solve package management/sharing and funding more generally?

While Element looks awesome, due to the 2 points above, this work falls outside of the scope of what we’d like to focus on at the moment.

4

Thank you for your feedback and encouraging words for Element… yes, I was honestly surprised at how well it does with those benchmarks, but there they are :slight_smile:

It is true that Element is currently facing the cold start problem. I am doing in-person presentations (next one on Monday coming) to generate the initial seed interest, feedback and traction to overcome this. It will be a long journey.

In response to your thoughts on the connection between Element and Radicle/Drips - I did think that this fell squarely into the “Alternative Interfaces” category - or at least almost squarely.

I will provide a fuller answer to two questions:

1: more detail about the interface between Element / Drips / Radicle - provided in case you reconsider either now or at a later date - some of this is different to what is provided in the original post above (can’t seem to edit that?) and is a much tighter integration with Drips especially

2: ideas for how I could contribute to the “could we solve package management/sharing and funding more generally?” question you raised - which is a good one.

Interface between Element Repository → Drips / Radicle ecosystem

I think to give a more updated and full context of how I see the Element Repository working with Radicle and Drips, I will put in here some rough notes that I made a few days ago after digging into the Drips documentation more deeply, and also as part of beginning to prototype the Repository. They are simple user stories of how developers would use the Repository.

User Stories

Element Package Repository

Page map:

/profile

→ ./funding

→ ./payouts

→ ./teams

→ ./invoices

/repository

→ ./dashboard

→ -> ./applications

→ -> → ./[My Application]

→ -> ./packages

→ -> → ./[My Package]

Developer Building an Element Application

  • I want to find a package that does “xyz” for my Element application

    • Go to The Element Web Framework
    • Search for “xyz”
    • View the listing and click to open the likely package’s page
    • I decide I want to use it for my application, so I can either:
      • copy the IPFS link and use in my application directly
      • OR opt to login, and add the package to an application record in the Dashboard and use the application’s IPFS link in my application importmap - the desired package is then included in that pre-bundled and optimized set of packages - which I can import into my application
        • The Repository will notify me if any of the packages in the application have new versions, so I can update if desired
      • Server-side processes implied: application bundling on application update + user notifications on package updates

  • I want to support the developers of the packages that I use

    • Go to Dashboard → Applications → [My Application]
    • Either: set a monthly contribution in the currency of my choice
    • And/Or: send a one-time contribution in the currency of my choice
    • I assign the funding source for the application - either crypto or fiat
    • Server-side processes implied: talk to Drips to set up drip list and related artefacts + fiat to Drips onramp integration

  • I am discontinuing my application

    • I go to the Repository Dashboard and delete the application, this will remove the bundle from IPFS and disconnect any fundings from that application
    • Server-side processes implied: talk to Drips to remove the drip list and clean up artefacts + clean up related fiat on-ramp artefacts

  • I want to set up a funding source

    • Fiat: Stripe Checkout (?) for a Subscription
    • Crypto: link Drips to token/wallet etc
    • Service-side processes implied: talk to Drips to link a token / stream (?) + talk to fiat on-ramp (Stripe?) to create the flexible subscription authorisation

  • I want to create an Element developer profile

    • Click on any sign in/up links across elementhtml.dev
    • Fill out the form
    • Optionally add one or more Funding Sources
    • Optionally add a Payout Target
    • Server-side processes implied: save profile data record + talk to Drips and link wallet/tokens/streams (?) + create fiat (Stripe?) authorization + Stripe Connect (?) for payouts

Developer Who Has Created a Package to Share

  • I want to publish my package on the Repository

    • I sign in / sign up with an Element account
    • Repository → Dashboard → Create Package
    • Fill in package details: name, description, source link, support link, docs link, dependency list, permissions (private / team / public)
    • Create a version (at Repository → Dashboard → [My Package])
      • Fill in form with version number and either IPFS CID, https url, Github/Radicle link, or direct upload
    • Server-side processes implied: save package data record + retrieve, verify and compile package files from upload/Radicle/Github/url/IPFS + pin to IPFS via NFTStorage(?) (even if already on IPFS) + talk to Drips and create Project and drip list to it’s dependencies (including Element!)

  • I want to unpublish my existing package

    • Repository → Dashboard → [My Package]
    • Set status to archived / delete (delete not available if someone using it)
    • Server-side processes implied: remove/update package record + possibly un-pin from IPFS + talk to Drips to remove project

Aside from the critical technical integration with Drips, the other integration is that Element will have the exact same user base as both Radicle and Drips - developers who value open source + the distributed web and wish to ethically create and use quality software that enables this ecosystem.

While it is true that that brings more benefit to Element than to Radicle at this point, however the overall barriers to adoption are lower for Element and the incentives to adopt are higher for Element than for Radicle - so in the long term it is not unreasonable to suggest that the net benefit a few years from now could be in the opposite direction. “Benefit” is defined here as one ecosystem bringing new users into the other ecosystem as a “warm introduction”.

In terms of Drips - this integration will at the very least serve to demonstrate its potential to serve as the real-world financial backbone of a complex developer ecosystem. It means that as I move to create enterprise adoption for Element (which is the main market that the Repository is intended to appeal to), those users will be required to become users of Drips at least indirectly.

“could we solve package management/sharing and funding more generally?”

The Repository will be built on four core web3 technologies:

  1. IPFS - all packages are stored/served via IPFS
  2. Lit Protocol - handles encryption for user authentication / access control and possibly future code encryption / gating
  3. Drips - financial backbone for both crypto and fiat (fiat will only be supported as a thin on-off ramp into Drips, probably Stripe Checkout / Connect)
  4. Ceramic - structured data storage / indexing / search

There’s nothing specific there which obligates it to only work with Element applications.

In fact, your question has got me thinking that an alternative approach could be to build this as a separate service not tied so closely to Element, which could be a web3 compatible package management service - I did already read the research report that someone did a while back looking at ideas around this for the Radicle ecosystem. The implementation would be 99% the same I believe.

Thinking on the fly a bit here, but I can’t actually think of anything that would be different except for it having it’s own domain, and ensuring that any Element-specific processes (if there are any) are created as plug-ins to the core system, rather than baked in - a good thing to do anyway, could have plugins to adapt to different frameworks and ecosystems as required.

If that is something that would be more in line with grant requirements, I would be happy to re-factor this application from that perspective, and as long as I can architect it in such a way to hit all the goals required from the Element Repository along the way, I think that would be a good initiative. I’m wary of scope creep, but this could be a rare example of it being worthwhile.

The more I think about it, the more I might just do it anyway :thinking:

Thoughts?

5

I’m going to break this grant application down into two separate grant applications:

1: a Drips - fiat on/off ramp
2: a general decentralized package management / sharing and funding service as described above

The on/off ramp will be small, simple project aiming to create a reusable on/off ramp integration for Drips, ideally as a custom web component that can be plugged in anywhere by anyone

The package management solution will be closely modelled on what I have described as the Element Repository in the original grant application, encompassing all those features plus what else is needed to for it to become a generalized solution for anyone.

I’ll have them both posted up here in the next day or two. Let me know if you have any thoughts about this in the meantime…

6

Thanks for the quick response @drpitman

I’m going to break this grant application down into two separate grant applications:
1: a Drips - fiat on/off ramp
2: a general decentralized package management / sharing and funding service as described above

Regarding Fiat on/off ramp

This is worth socializing with the Drips core team. They’ve likely given this some thought and may provide some good direction. I’ve dropped a note to them on Discord.

Regarding decentralized package management

2 points:

  • This is worth socializing with both the Radicle and Drips core team.
  • I’d like to challenge us to distill this into a few diagrams that help visualize the overall picture. I don’t think the details above are easily digestible. This is a common problem I see when we’re deep in the weeds of our ideas. I think coalescing the various components and flows between them might help visualize the end-to-end picture here. I’m happy to hop on a call and go through this together. I don’t mean to say the ideas are off; rather, I have qualms about anyone else digesting it without this exercise, so as a matter of due diligence would like to do it.

Let me know your thoughts on the above.

7

Thanks for this, feels like I’m getting close to the right track here…

Yes, I can jump on a call pretty much anytime in the coming days except tomorrow (Monday) evening Australian time.

I saw the Discord post asking for thoughts on the fiat on-off ramp, I’ll keep an eye on that to see what anyone else has to say about it.

Thank you for your thoughts so far and let me know when you’d like to do the call…