Offchain Typescript library

A library based on Typescript can both ensure web and mobile (React-native) easy integration and built-in documentation while coding

- building and maintaining the "cardano-wallet-interface" npm package used to abstract wallets differences

- Single Pool node Operator(Harmonic [ARMN])

[IMPACT]

Typescript is with every probability the go-to language when choosing to develop a large web application

frameworks such as React Vue and Svelte support it and Angular even makes it a must.

Adding an easy way to build transactions using Typescript will make the smart contract developers working experience as sweet as writing declarative code while having all the control of the imperative one

possible features are:

- automatically generated Metadata given a (JSON) serializable object

- SmartContract endpoints translated to simple transactions built in the browser (reducing or even removing a centralized server load)

- extremely easy blockchain queries by using the browser fetch API, either requesting to existing API providers or a private Server running cardano-node

example of integration:

- automatic metadata:

an object like

-----------------------------------------------------

{

   message: "Hi Alice here's 50 ADA as a gift for your birthday!",

   sender: "Alice's grandma",

   LovelacesPerUSD: 10000000

}

-----------------------------------------------------

would be encoded directly as a CBOR map as

-----------------------------------------------------

a3676d6573736167657833486920416c69636520686572652773203530204144412061732061206769667420666f7220796f7572206269727468646179216673656e6465726f416c6963652773206772616e646d616f4c6f76656c616365735065725553441a00989680

-----------------------------------------------------

same would apply for PlutusData instances (Redeemers and Datums)

which would be converted following the ascii encoding whenever possible, therefore becoming:

-----------------------------------------------------

{

h'6d656173616765': h'486920416c69636520686572652773203530204144412061732061206769667420666f7220796f757220626972746864617921',

h'73656e646572': h'416c69636527736772616e646d61',

h'4c6f76656c61636573506572555344': 10000000

}

-----------------------------------------------------

and then encoded in CBOR

-----------------------------------------------------

a3476d6561736167655833486920416c69636520686572652773203530204144412061732061206769667420666f7220796f7572206269727468646179214673656e6465724e416c69636527736772616e646d614f4c6f76656c616365735065725553441a00989680

-----------------------------------------------------

this would be done without the need by the developer to know it even happens

- an other planned feature is smart contract usage

provided a smart contract address, something as follow would ne possible:

const myAwesomeSC = new SmartContract("SC addr");

interface RichnessParams {

   howRich: "somewhat rich" | "rich" | "very much" | "jeff who?"

}

myAwesomeSC.defineEndpoint("makeMeRich", ( parms: RichnessParams ): { datum: SmartContract.Datum, redeemer: SmartContract.Redeemer } => {/*…richness code … */} );

myAwesomeSC.callEndpoint("makeMeRich", { howRich: "very much" });

```

the project will be open-source

everyone will be able to watch the project progresses,

also, major advancements will be published on Harmonic's Twitter page ( https://twitter.com/HarmonicPool )

like every software, a major challenge is code reliability and security.

Those risks would be minimized through constantly testing the code written

[FEASIBILITY]

project main milestones would be:

- ensuring efficient CBOR interoperability ( with JSON, PlutusData, etc. )

- sending a simple Transaction, lovelaces only as value

- sending multiasset transaction

- Minting policies interacion

- SC interaction

- Certificates management ( registration and deregistration )

- 50'000 USD as the average salary for 6 months of full-time development, ensuring project delivery AND valuing any contribution to the project itself

-15'000 USD further maintenance costs

for cost reduction reasons mainly the project will start with only one person working full-time on it

when the software will be delivered and new (possible on-chain) features will be added, having more members would be a better choice, but the on-chain part is not included in this proposal

[AUDITABILITY]

as said before the project will be opensource, therefore Github commits will be a great way to measure the development of the project

developer and organization adoption of the library would be for sure a form of success of the project

no proposal before this one