In the spirit of transparency and accountability I’ll be sharing with the phonon community what I have achieved each week in my role as lead community developer. Please don’t hesitate to ask questions here or reach out in discord.
Week starting 21/11/22
I began designing and developing task three of my mandate “On/Off-Ramp (Onboarding new Cryptocurrencies into Phonon)”.
After talking with members of the core dev team it has been decided that this will consist of a golang package that exposes card functionality through a REST api. Native apps including this package can offer a Metamask like experience where third party web apps must request permission from the user before being able to access specific card actions.
Currently we are referring to this package as “phonon terminal”.
Boop.eth and I are still discussing specifics but the goal is for the official phonon wallet to include this package so that users can manage web app permissions and their wallet from one interface.
You can see my progress in the video below. It illustrates the very early stages of development of
an example web app build using my “PhononTerminalJS” package
web app requesting permission to read a user’s connected cards
the native app prompting the user to accept the “READ_CARDS” permission
the native app pushing updated permissions to the web app.
the web app fetching connected cards
native app pushing insert and remove card events to the web app
Goal for next week: Have all card functionality accessible via the web server and each endpoint restricted by a specific permission.
Week starting 28/11/22
I continued developing the terminal golang package, JS SDK, example 3rd party web app and native wallet app.
My goal to finish all the card functionality and events was not hit as I did not add card pairing and phonon sending functionality. This functionality is easy enough to add as the logic can be imported from Gridplus’s phonon-client package but it does raise questions around if the terminal package should be opinionated on how cards are paired and phonons are sent. I will start a discussion with the core devs.
Added the following card functionality
Web app
Request card unlock
List Phonons
Create Phonon - Triggers “phonon created” event to apps with “read phonons” permission
Set Phonon Description - Triggers “phonon updated” event event to apps with “read phonons” permission
Request Destroy Phonon
Native Admin App
Unlock Card - Triggers “card updated” event to apps with “read cards” permission
Grant Destroy Phonon - Triggers “phonon destroy” event to apps with “read phonons” permission
General
Web app permissions now persist after shutdown. Permissions are saved to a JSON file on the user’s machine.
*Web app Cookies are now valid after shutdown. The app loads the secret from a config file on the user’s machine.
A native app that imports the Terminal golang package can be granted “admin” rights so it doesnt need to ask the user for permission to access card functionality.
Design Discussions
Boop and I are still discussing if the terminal will be a standalone app or be integrated into the new wallet he is working on.
Should the terminal be opinionated on how cards are paired and phonons are sent? The session package the terminal imports is opinionated. This needs further thought and discussion with the gridplus team.
Goal for next week
Terminal
Make the terminal repo public and somewhat documented
Add pairing and sending logic to the terminal package if it is decided to use the logic for the phonon-client package repo. If not, design how custom sending and pairing logic can be added by native apps.
Decide if the terminal package will be integrated into boop’s new wallet or be a standalone app.
General
Write a high level overview of how a potential Phonon DEX could work for Mickey.
Unfortunately I was out of action for most of the week due to illness. Will be back to full capacity next week.
Wrote notes for Mickey’s investor meeting
Brainstorming the CA system with Rake.
I have pushed my progress on the phonon terminal but no changes were made this week except for some refactoring and notes in the readme GitHub - ahinchliff/phonon-terminal
Boop and I have decided that his Phonon Manager wallet will provide a UI for managing web app permissions so there is no need for phonon terminal to be a standalone app.
Still need to discuss with the core team how pairing/sending logic should be added to the terminal.
In the last product meeting it was decided that the terminal module should leverage the current pairing/sending logic found in the phonon-client module. This may be changed in the future when we get around to implementing p2p pairing/sending.
Boop and I have settled on a rough plan for how the terminal module will be integrated into the new wallet (it looks amazing). Once Boop has implemented how he wants state management/api calls to be done I will hook up a few features using the phonon-terminal-js SDK I am working on. This should begin soon after the new year.
Progress
Added pairing, sending and initialization endpoints to the terminal. The terminal should now have feature parity with the http package found in phonon-client.
Wrote an extensive test suit covering permissions and phonon-client integration. This will be helpful when adding in the new beta features.
Started work on an example Bitcoin “on/off ramp” web app which is a continuation of the “web app” I mentioned in previous weeks. The app will allow users to create, fund & redeem Bitcoin phonons and provide an example of the permission flow.
Discussion points
I am currently unable to build my native wallet app using Wails as it is conflicting with the fyne.io package in phonon-client module. All I need to import from phonon-client is the session/model/remove packages. For now, I am developing against a local branch where I have removed the GUI logic. Do we have plans to remove these things in the beta branch?
Web apps need a way to add new assets to the terminal. I am currently thinking through a flow where users can approve new assets similar to adding a network to metamask. This would include asset name, asset id, an asset icon and a url for verifying the phonons with that asset id. The verification url would take a public key and return the denomination of the asset. Interested in hearing people’s thoughts on this.
I haven’t posted an update in the last month because I haven’t been focusing on development tasks. The last few weeks have mostly been spent focusing on discussing and designing the next version of the phonon applet based on Posted Phonons. I imagine this will continue to be the case for at least the next month. Once a spec is finalised I’ll most probably move back onto developing projects for the phonon ecosystem. To keep up to date with the discussion checkout the #protocol channel.
Deployed the site and smart contract for claiming alpha testnet rewards. This can be viewed at https://rewards.phonon.network/. Claims will go live once the multisig deposits PHONON into the smart contract.