Thanks 1337bytes,
keep up the hard work. Its always great and difficult to share user/usage information in the beginning.
Hope to see cool things …
As mentioned above, there is a lot of extra work for the current milestone that I hadn’t foreseen. I’m making progress currently with building an Elemental Zcash SSO server (OAuth2 Provider), a full stack authentication system built from scratch, which will allow for registration, login, etc; things could’ve been sped up by using a framework or third party auth system, but am prioritising future proofing instead and don’t want to trust any third party/proprietary solution, use JWT, or use Ory Hydra without a solid understanding of Go incase debugging or custom features are needed. Given app adoption, OAuth2 support should allow for cool use cases like “Login With ZECpages” or “Login With Free2Z”. This probably should’ve been a milestone or two on its own.
Code here: Initial auth GraphQL/OAuth2 provider setup by macintoshhelper · Pull Request #1 · elemental-zcash/sso · GitHub . Currently, the unverified email user creation flow is working; next step will be creating a Dockerised transactional email system (with Postfix most likely). Am not keen on requiring AWS SES usage given that the API isn’t widely adopted like S3.
I’m using a custom ORM that I’ve built, elemental-orm
, which is quite a bit of extra work initially, over using an existing ORM or manual SQL, but am doing this for future proofing and faster feature development in the future; the goal is to have the same data models create PostgreSQL schemas/queries, Redis indexing, etc and have a performant/scalable single source of truth. I’m not aware of any existing Node.js ORMs that nicely integrate PostgreSQL/Redis.
Once this is done, I’ll integrate the SSO server with ZPublish user registration, create a profile page with zaddress
/UA
entry and an all my links style page with the Elemental Pay donation flow, and an import for the Twitter data download (will probably do this in a future milestone once I’m more caught up on higher priority tasks).
TLDR; building a custom Redis/PostgreSQL ORM and SSO server has delayed things, but hopefully will be a really nice toolset for developers to build scalable Zcash apps, and will be extracting things like the GraphQL setup for Relay.js support and having a nice GraphQL/Apollo compatible API for building mobile apps (can then do things like create a GraphQL Zcash RPC API with caching).
An initial version of the front-end of Elemental Pay has been published to npm: @elemental-pay/components
. For now there’s just a minimal invoice flow, I think it’s best to move onto the next milestone (Point of Sale) now, given that a lot of extra work has already been done for the current milestone, and incorporate the payment listening/processing backend API as part of that, and it’ll expand on top of the invoice components together with a merchant backend. A lot of preparatory work has already been done for the Elemental Pay backend with the SSO server backend implementation, as mentioned above: Initial auth GraphQL/OAuth2 provider setup by macintoshhelper · Pull Request #1 · elemental-zcash/sso · GitHub (apologies for the massive PR, need to split things up more for easier code review ).
Here is the Linktree inspired app with a donation button/flow (deployed to staging for now since database may be wiped until it’s more stable): Elemental Zcash SSO And user registration is possible here: https://sso-staging.elementalzcash.com . For now, the code lives in the SSO repo to speed up deployment, but will be extracted into the ZPublish app soon and the SSO app/server will most likely be shared between ZPublish and Elemental Pay (for online/physical merchants). Once that’s done, Twitter backup/takeout import (to bypass API quotas) can be done (lowish priority for now unless someone specifically requests this feature) together with Twitter verification with OAuth2 (can use it to search/find Zcash address and social media profiles by Twitter username).
Am planning to experiment with adding a Sign in With Zcash
authentication alternative to email/password for Elemental Zcash SSO by using zecwallet-cli
’s encryptMessage
to send an encrypted token that can be decoded with decryptMessage
on a local machine with the published Zcash address’s viewing/private key – in the style of email magic authentication links, as encrypted Zcash memos that are fee-less by not being broadcast; drawback being this requires CLI access unless the feature is integrated into mobile/desktop wallets, and there may be security drawbacks in case people publish their viewing key (could have a separate private authentication-only Zcash address in that case maybe).
This feature has been on my wishlist for a while, glad to see it being worked on.
Hi, apologies for the lack of updates and progress! I’m nearing the completion of the fifth milestone and will be making another post once it is complete.
Here is an updated link for the grant proposal on the new grants platform: Gallery View: Zcash Community Grants Program
Building an SSO/authentication server and scalable payment processing backend infrastructure has resulted in considerably more time and work being needed than I had anticipated for the payment processing milestones. I ran into a bit of a dead-end with the TypeScript GraphQL/PostgreSQL database architecture that I had built; the codebase became too tangled and would’ve been unstable and slow to add new features to. I’ve decided to build a Python Flask microservice REST API for the SSO server (OAuth2 provider), and am replicating this architecture for the backend of Elemental Pay. Code for the Flask server here: Python microservice refactor by macintoshhelper · Pull Request #4 · elemental-zcash/sso · GitHub . Have been working on some test coverage too.
Soon I’ll publish the Elemental Pay website with the proof of concept Point of Sale payment flow; this will be usable by physical merchants on a smartphone (web app) and will work with a viewing key and in-conjunction with a wallet app of the merchant’s choice. After the implementation of a front-end flow, I’ll work on linking up the account system backend and dashboard for merchants with invoice support, etc.
Re Twitter integration, the official Twitter API has become virtually unusable for third party clients due to the new pricing model and new rules that state that it is not allowed to “create or attempt to create a substitute or similar service or product to the Twitter Applications”. As part of the last milestone, the 1.0.0 release of Elemental Zcash, I’ll integrate Twitter sign-in to ZPublish (which will work in tandem with the sign-in with Zcash SSO feature) and a proof-of-concept tweet import feature into ZPublish using the Twitter data takeout JSON.
This grant has taken considerably longer than planned; this is mostly due to the fact that I’ve been trying to accomplish too many different tasks and context switch between different codebases/projects and the backend infrastructure has been a lot more work than I expected. I’d be keen to focus on developing Elemental Pay after this grant and depending on community enthusiasm, would like to apply for additional funding for Elemental Pay (I’d be happy to continue working on it straight away and could apply for retroactive funding if community feedback is positive). After some user testing and adoption, Elemental Pay should have a nice path forward for being able to bring in some revenue from merchants that would prefer to use a hosted option rather than self-host the open-source repo/platform themselves which should make the project sustainable in the future.
I’ve published the proof-of-concept Elemental Pay Point of Sale app here: https://elementalpay.com/ . Source code here (Next.js server): elemental-pay/packages/web at main · elemental-pay/elemental-pay · GitHub . This is a client-side demo for now (no account needed). A merchant can input their business name, Zcash address for their own custodial wallet, and price amount, show the customer the QR code and a token is generated on the backend and encoded into the memo and is displayed back to the merchant to verify in their wallet app.
I feel that it’s best to delay implementing the Liberated Payments inspired flow for now as the ZIP is still a work in progress, and upon further research I’ve decided that it should be sufficient to allow 0conf transactions for lower value purchases and as far as I understand, this flow wouldn’t really prevent a double spend as the customer would still have the private/spending key, so there wouldn’t be much difference to a conventional transaction. A paper wallet style flow would be more useful, but should probably remain a low priority for now until user testing has been done and merchants are already actively using the app.
An initial minimal version of the SSO/OAuth2 server is near completion now. I feel that it’s best to move the publishing of the payment backend API forward to the next/last milestone. As part of the last milestone I plan to publish/deploy the SSO server and link it up with Elemental Pay and ZPublish, giving them an account system, finish implementing Sign in With Zcash
authentication, and publish Elemental Pay 1.0 together with the invoicing/merchant/payment listening API and Elemental Zcash 1.0 with the SSO server as part of it (front-end components and backend server components).
— EDIT —
An alpha version of the SSO server is now live (email and Zcash address auth disabled for now, I implemented (random) account ID and password login for now to not block development on Elemental Pay. Am planning to implement Login With Zcash
with both encryptmessage
/decryptmessage
for CLI users (no transaction needed) and on-chain verification token sent to your wallet in a memo to verify zcash address ownership, until mobile wallets support decryptmessage
, then will be able to login with zcashaddress as a username and your password, and the SSO server will act as a “guarantor”/trusted verifier of the Zcash address ownership; the transaction fee will need to be funded with an initial transaction to open the account. https://sso.elementalzcash.com/ Please keep in mind that accounts will likely be deleted for 1.0 release.
The OAuth2 flow for logging into Elemental Pay (payment processor) with Elemental Zcash SSO is working locally, and will deploy this for demo purposes soon. Code here: Initial user login/signup flow with Elemental Zcash SSO | PR #1. Next steps will be working towards a MVP/1.0 release of Elemental Pay, with a merchant sign-up process, implementation of a Point of Sale merchant dashboard with invoicing API (built on top of zecwallet-light-cli
– will probably implement this as a Flask microservice). And 1.0 release of Elemental Zcash with documentation. Then will implement a backend for ZPublish and integrate the donation app as part of that together with tweet import. Any feedback/ideas appreciated.
Hi, an update on the last milestone and current state of the project:
My laptop logic board died a couple months ago, and I was unable to get it repaired until last month, which has unfortunately delayed things; I had got a second laptop meanwhile, but it was slow and problematic to work on. Am making faster progress now that my main laptop is working again.
I’m nearing completion of the last milestone (1.0 release of Elemental Zcash and Elemental Pay) and have been working on automated setup scripts and documentation, including Storybook apps for documented examples of the component libraries to allow for easier integration into apps.
I am doing a bit of a rewrite of the zecwallet light interface to use ephemeral Docker containers for payment listening, this is requiring quite a bit more work than I had anticipated and has been slowing my progress. I will then be able to do a 1.0 release of Elemental Pay with an invoicing API.
Tasks left to do:
- Finish zecwallet light interface API (for invoicing, SSO encrypt/decrypt message, viewing key imports for Point of Sale)
- Finish off environment generation scripts (OAuth client IDs and secrets, env secrets, Docker Compose setup, etc)
- Finish documentation (Storybook stories)
- Migrate donation web app to ZPublish, integrating Elemental Pay component library (with client-side flow) and optional server-side flow with payment listening, if the user has submitted their viewing key to the SSO server).
- 1.0 release of Elemental Zcash, Elemental Pay and Elemental SSO.
I’ll be publishing a 1.0 release of Elemental Zcash, Elemental Pay and Elemental SSO today. I’ve pushed the latest code to GitHub for them already. And I have published a minimal version of https://zpublish.org with live payment listening support.
Took a lot more work than expected to get it all working, but I’ve finally got a nice system working for payment listening/processing. Linktree style donation page here, with static Zcash donation Elemental Pay invoice UI if only a Zcash address without viewing key is provided, or if a viewing key is provided, it’ll provide a live update when the payment has been received https://zpublish.org/user/clns64o3l0000no01lu4vw5kj
I plan to continue working on cleaning up the code, fixing bugs, introducing automated testing, CI, etc for the next couple of months and am thinking of applying for another grant to focus on Elemental Pay improvements.
It took quite a bit of rearchitecting to get the zecwallet light interface API for Elemental Pay into a usable state; initially I was wrapping zecwallet-cli
, but found this to be too unstable and hacky, and abandoned these efforts in favour of using zingolib
. I developed @elemental-zcash/zingo-node
, an npm library with Node.js bindings to the Rust zingolib
project. For now, it’s in an experimental stage, but in the future, this could be evolve into an official Zingo SDK for Node.js/React Native.
Using the Zingo node bindings (with x64 Mac/Linux Docker compatible prebuilds – Release zingo-node-v0.0.1-beta.9 · elemental-zcash/zingo-node · GitHub), I created a JSON-RPC REST server exposing zingolib
commands like initialising a wallet from a Unified Viewing Key, listing transactions, encrypting/decrypting messages/memos, etc which can run in a Docker container. There is a gateway server that uses Docker as a function (inspired by zcashblockexplorer.com viewing key imports), spinning up a ephemeral Docker container with a Zingo wallet. https://github.com/elemental-pay/wallet-service/blob/main/packages/zec-rpc-gateway/zingolight/api/api.py .
In the next couple months, I plan to experiment with building a custom Zcash wallet based off zingolib
with a redo of the UI, and hopefully as part of this, contribute improvements upstream to Zingo wallet and possibly work on an SDK ecosystem that would make Zcash wallet development easier (i.e. in the lines of Bitcoin dev kit – BDK-RN: Building React Native Apps with BDK | Bitcoin Dev Kit Documentation ). This would make it easier to surface features like decryptMessage
to an end user via UI for use cases like signing in with Zcash or resetting a password by proving ownership of a Zcash address/viewing key (decrypting a reset password/verify address token).
I set out to work on too many different goals for this grant which unfortunately led to many delays, and I ended up changing some of my priorities. As mentioned earlier, I decided not to work on a custom Twitter client/integration due to the removal of free API access, and am not sure that this is something that would be used much in any case. And in terms of ZECpages/memo.cash protocol support, I feel that it’s better to not rush into developing something that may not be used much (at least without user interviews/testing), and wait for Zingo and Brave adoption of a memo protocol before development on this. The SSO server was out of the scope of this grant and contributed to the delays, and I worked on this instead of some of the social-media focused features, which I felt was more important, as this opens exciting possibilities for privacy-focused login.
TLDR;
- Publishing a 1.0 release of Elemental Zcash components and Elemental Pay today.
- Elemental Pay payment listening support with backend Zingo wallet (with ephemeral Docker containers that expire after 6 hours – invoice expiry)
zingolib
Node.js bindings.- Can be expanded to a Node.js and React Native Zingo SDK ecosystem for app/wallet devs
- Privacy-focused SSO server for ZPublish/Elemental Pay, and could be adopted by other projects like ZECpages or Free2z – will offer account recovery via Zcash memos
- Plan to continue working on fixes, cleanup and features in the coming months
- Future grant ideas: Zingo or warpsync React Native SDK and Elemental Pay as a service (could generate revenue on its own in the future by offering a hosted SaaS option as an alternative to Coinbase/Bitpay/Stripe).
Congrats! Props to pushing this over the finish line.
Did you complete the documentation?
Sorry for the delay. I’ve pushed the latest Storybook documentation with code examples:
Elemental Zcash Components | Storybook
@elemental-zcash/components
ZPublish Platform Components | Storybook (for now the ZPublish components are focused on internal use in the zpublish.org app, so documentation is minimal)
@zpublish/components
Elemental Pay Components | Storybook (static and live invoice integration example code)
@elemental-pay/components
Hi, a quick update:
Unfortunately I’ve been a bit inactive lately and haven’t had time to continue with the work from these projects. Am planning to revisit some of the work from this grant and work towards decoupling it and spinning it off into some new user facing projects. Once some progress has been made and there has been some user feedback and traction, I am thinking to apply for a new grant to support this effort.
There were a number of oversights around some of the planning and development that I will be taking some time to hopefully address retroactively: namely around technical architecture, that made things hard to build upon and maintain.
The Elemental Zcash SSO project ended up replacing some of the goals such as Twitter client. I’m going to explore the idea of porting the SSO project to using some open source solutions like Ory Kratos and NextAuth. I believe there’s a lot of potential to having emailess auth with a pseudonymous account ID/number and Zcash memo auth.
I think changing the direction of Elemental Zcash to be more of a language and framework agnostic set of inspiration and UI/UX guidelines and design tokens, rather than prebuilt UI components is best. UI frameworks are too much of an opinionated choice and locking Zcash app/wallet developers into specific libraries like styled-components
makes it difficult to gain adoption. A shadcn
style approach will be best going forward, together with WebComponents, CSS variables, Design Tokens JSON templates.
I would like to evolve ZPublish into a Substack alternative that integrates with Elemental Pay. And later on work on a custom Free2Z and Bluesky client that can integrate with Elemental Zcash SSO.
I will likely retire this thread soon and create some new/separate threads for spin-off projects.
Small poll for what people think should be the main priority for working on:
- Elemental Pay – Stripe API/components for Crypto
- ZPublish – Bluesky and Free2Z Client
- Elemental Zcash SSO – Sign-in With Zcash
- ZPublish – Self-hosted Substack
- Elemental Zcash SSO – Sign-in With Zcash
- 100% ZPublish – Bluesky and Free2Z Client