After someone attempts to generate an invite link, and after we check that the account-sys applet is in the same application group as the invite-sys applet, then we need to actually:

• Generate the link
• Store the invite object on chain.
• Display it to the user

There are various actions in the fractally process that require multisig support.

• Council defining system parameters
• Teams modifying their membership
• Council approving petitions (for eviction, and other actions)
• etc

Develop multisig auth service

The main thing to compress is the contracts themselves. Not sure most of the other data is all that compressable; however, if we use the compression technique from protocol bufs along with my flatbufs then we should compress out the 0's. Simple format.

https://github.com/gofractally/newchain/blob/efc4e03af00aa8c117031368dc73d29c65a395c2/libraries/newchain/include/newchain/block.hpp#L55

The benefit of using TAPOS info is that transactions in the "dedup" cache would be co-located and potentially easier to find.

https://github.com/gofractally/newchain/blob/efc4e03af00aa8c117031368dc73d29c65a395c2/libraries/newchain/include/newchain/block.hpp#L37

Add a UI to the invite applet that knows how to pop up a modal asking the user to grant permission for another applet to generate an invite link.

It should be simpler to add additional command line flags to change the behavior of psitest.
I will make it more configurable, and start by adding a flag to control whether it prints transaction times.

Brief description

Election mechanic allows members of a fractal to submit their votes in weekly meetings to a psibase service

Dependencies

• The token used for the fractal

Responsibilities

• Unlocks automatically on time for consensus attestation
• Stores winner information
• Distributes funds

much more comprehensive spec needed

Background

A fairly common pattern is for contract authors to require some one-time initialization on their contract before the contract should be used. To achieve this, authors will add an init action which performs the configuration and sets a flag in the database. Every other action that depends on the initialization should remember to assert that the initialization happened.

Opportunity

Setting up the database flag, the init action, and asserting on the flag is all boiler plate that must be done for each contract. Therefore we could improve developer experience, and enhance security (negate risk of forgetting to assert), if we had a system people could use to achieve this.

Implementation

This is just one possible implementation. If a contract class has a specially-named function called initialize(), then our dispatcher could modify its behavior in the following ways:

1. If initialize is called, it calls initialize on the contract base class instead of the child class, which sets an init flag in a standardized db row, then forwards the call to initialize to the child class for performing the actual init.
2. Before dispatching every other action call, it asks the base contract class if the initialized flag is set

Conclusion

This would be an optional mechanism to help make writing contracts faster, and help with security by eliminating the possibility that a developer forgets to assert on the init flag.

Allow smart contract authors to create tables of records with an auto-incrementing primary key.
Allow smart contract author to query next available key.

Initial version

Capabilities

The symbol contract allows people to create symbols (essentially buying them from the network), list them for sale on a public market, and unlist or buy them from the market.

The symbol contract is coupled to the tokens contract such that a symbol owner (who also owns a token) can transfer the symbol to the token contract, and then call an action on the token contract to permanently map that symbol to their token. The NFT that represents the transfer rights of the symbol is burned by the token contract when this mapping takes place.

Symbol pricing algorithm

Before creating a symbol, a user must credit the symbol contract enough funds to cover the creation of their new symbol. The cost of a symbol starts out at an arbitrary number, and adjusts every 24 hours according to the following algorithm:

if (number of symbols created in the last 24 hours > 24)
    cost = cost * 1.05
else if (number of symbols created in the last 24 hours < 24)
    cost = cost * 0.95

In this way, the cost of symbols will adjust according to market forces to target a rate of one new symbol created per hour. Symbols of different character length are priced independently.

Future version

Future version will allow additional administration functions, such as the ability to

• update the symbol pricing rate of increase/decrease
• for each symbol length, update the floor price and the target number created per day

Introduction

Update the app directory on the home page to allow app developers to register their own app information for it to show up on the directory.

Metadata should at least include:

• Name
• Icon
• Short description
• Long description

Furthermore, add a search bar for users to search the apps in the directory.

What are the pros/cons of standardizing how our signatures/keys work with BTC?

https://github.com/gofractally/newchain/blob/efc4e03af00aa8c117031368dc73d29c65a395c2/libraries/newchain/include/newchain/block.hpp#L59

This is probably the single biggest improvement for crypto functions and would provide a big differentiator.

There's noticeable delays in loading applets. Very brief analysis shows that the same resources are being requested from servers multiple times. This should be avoided.

Events can currently be emitted in contracts, but there's no way to confirm in a unit test that they are being emitted properly.

1. Interblockchain Communication - Some events need to create merkle proofs
   • should be readable by contracts for a limited period of time

        addmerk( data ) {
                  auto seq = gseq++;
                 sha( seq, contract, data ). /// subjectively log data for wasm plugins to leverage
                 return seq;
        }

2. Inter-contract communication - Some events need easy reference by other contracts (no merk proof required)

   • JUST THE DB API
   • should be readable by contracts for a limited period of time
   • events written to their own table, observers can query this table for updates.
   • if I want merkel proofs then I also call a native call with a hash

3. UI communication - Some events don't need any proofs, but are still useful for queries

   • DB - Write-only, read never in contract, read from query
     put, remove - can be NOOP on some nodes...
     - mutable subjective queries that can also write (node operators only, because it is on main thread)

Minimal UI needed to interact with the election contract

Takes a blob containing a bunch of actions, authenticates them, then sync call with override sender permission.

Note: cannot dispatch an action to a contract without code.

      struct action {
               unit32_t     sender
               uint32_t     contract;
               bytes           data;
      }
      using claim = { proof_contract, vector<char>};

      struct transaction {
              tapos
              expire 
              vector<actions> actions;
              vector<claims>   claims;
      }

Example Transfer:

      transaction = {
             actions [
                     {   sender: user,
                         contract: tokens,
                        bytes:  = variant < transfer, ... > 
                                  function_num = transfer = 0,
                                  { from, to, amount, memo, ...}
                        }
                   }
             ]
      } 

Unit tests can just use action wrappers.... except, they need sender-override capability on action wrappers.

To execute operations, an applet needs an API to define and submit them.

Operations contain operations, or other actions.
Core needs to do a depth-first traversal of the operation and add all actions into a transaction object.
Then the user's specified auth contract is loaded in an iFrame, asked to sign the transaction.

For MVP, no need to ask for permission from each applet. All applets are assumed to be part of the same application group.

Then core submits the signed transaction to the chain.

Add infrastructure such that custom objects receive a call like:
static void fracpack_validate(CustomType param)

Which allows them to do custom context-free validation, such as that a number is within bounds, etc.
That allows checking for parameter validity to be in one place, rather than spread among many actions, increasing contract security.

Query needs to work for the token applet so that it can load and show all events up until the present moment.

Block head info not being correctly populated into block objects, causing transactions to timeout and other issues.

Description

Token creators shall be able to publish contracts that customize the behavior of their tokens.

Implementation

The token contract shall allow holders of the token issuer nft to register custom contracts with their token. If a token has a registered contract, then actions with specific names will be called on the registered contract to facilitate custom behavior.

More details needed about what the hooks are and what kinds of behavior is customizable.

key {
uint32_t account/contract;
char[] userdata;
}

        kv_get( did, key ) => size  or -1 for non-existing
        kv_put( did, key, value)
        kv_greater_than( did, key );
        kv_greater_equal( did, key );
        kv_less_than( did, key );
        kv_remove( did, key ); 
        get_result( char* buffer, size ); /// general API for any call that returns something other than an int
        get_current_action(...) /// called by dispatcher which saves the account / sender /etc

No good reason for Token to be dependent on Symbol here

Goal

Create a straightforward flow to allow users to invite new users to the blockchain and pay enough to give the user some initial resources and a premium name.

Design

As a user interacts with the chain, they consume CPU. Of the network tokens used to purchase that consumed CPU, 80% shall be burned, 20% shall flow into back to the user into a balance that can only be used to invite new users. This balance can be called "invite credits."

At any time, an account may interact with the Invite applet to create an "invite" for a dynamically calculated cost. The cost of the invite is 20% greater than the sum of the following on-chain metrics:

• The current cost of the storage for a new account
• The current cost for a premium name

An invite is an object that stores:

• The user that invited the new member
• The app that invited the new member (if a specific app was instrumental in facilitating the creation of the invite link)
• The invite credits

This creates a unique link that the inviter may share with an invitee. After the invitee clicks the link, they may create their account, choosing between a basic name or a premium name, and any leftover funds get allocated into the new account's CPU budget.

As the new user users the blockchain, the network tokens used to purchase their consumed CPU will be directed to the regular liquid token balance of the inviter rather than the invitee's invite credit balance. This will continue until the inviter has been reimbursed 2x the cost of the invite, at which point the invitee's invite credits will start accumulating normally.

Questions

• Should invite links expire?
• How should we handle when the invite credits no longer cover the cost of the account creation + premium name, or if there are no credits leftover to add to CPU budget?

Proposals

• What if, instead of the 2x repayment, invitees pay 5% of the cpu-consumed network tokens to the inviter in perpetuity?

Design artifacts

Problem

Currently, every time a change is made to a js or html file that gets uploaded to the chain, the easiest method to see the update is to kill the chain, and restart a test file that configures a new test chain and re-reads/deploys the content from disk to the new chain. This is cumbersome, and a barrier to entry - Most front-end devs are used to hot reloading during development where updates to their files can be immediately reflected on a local web server.

Solution

For development experience, we should have a tool that watches specified files or folders for changes, and then uploads the modified files to a local test chain.

Ideally, there should be a websocket connection between the node/client to allow the node to tell the client to automatically update its view of the applet.

My new serialization library would enable tranasctions/blocks to be parsed/accessed without deserializing. This would dramatically improve performance.

Thoughts?

https://github.com/gofractally/newchain/blob/efc4e03af00aa8c117031368dc73d29c65a395c2/libraries/newchain/include/newchain/block.hpp#L44

Accounts (the actual psibase::AccountNumber) shall own an NFT which represents the authority to sign for that account.
The auth delegation contract should also allow people to register another NFT as an authorized signer on their behalf when using a particular contract.

Needs much more detailed spec

Current Test Syntax

chain.as("alice"_a).at<NftSys>().mint();

"as" creates the user context, and "at" specifies the contract interface with which the caller is interacting.

Current Contract Syntax

actor<NftSys>(contract, NftSys::contract).mint();

Desired Contract syntax

at<NftSys>().mint();

...or if I wanted to sign as someone else, I could use:
as("alice"_a).at<NftSys>().mint();

Proposed Implementation

Use CRTP to give the contract base class access to the child contract name:

class MyContract : public psibase::Contract<MyContract>

Then the base class can provide the desired as/at syntax.

Drawback

Forces all contracts to pass themselves into the base class.

Add some documentation with details on how transactions are executed in psibase.

I want to know expensive it is to make a synchronous call into another contract the first time (when a new execution context must be opened), vs subsequent times in the same transaction (reuses the existing execution context).

The answer may help contract authors decide how to design their interfaces, should they prioritize smaller, simple functions? Or more complex, monolithic functions?

Change the sync call to a transaction submission.
Return a type templated by the actual return type and the trace.

Description

According to the wallet front-end mockup, we need the ability to send tokens to key, and the sender pays the fee to store the tokens. A key can then be converted to an account.

Implementation

The token contract shall understand that credits to a special account called "pubkey" are stored in a balance tied to the public key specified in the memo of the credit action.

When someone calls debit with the pubkey account listed as the sender, and a specific public key listed in the memo, then the debit action will succeed if the public key is in the transaction's claims, and will debit from the corresponding public key balance.

Extra details

• transaction-sys needs a new action for contracts to fetch all claims
• to confirm the public key is in the claims, simply look through all claims until the contract matches verifyec-sys and the content matches the public key.

1. Proxy Object on Caller Side (action wrappers)
2. Dispatcher on Receiver Side

      class othercontract {
             flat<string> callme( flat<string> hello );
      };
      REFLECT( othercontract, (callme, p1, p2, p3)  )

     template<int funcnum, typename R, typename Params...>
     struct memberobject {
     }

     proxy {
          memberobject callme() { return membeobject<...>(contract) };
          flat<string> callme( flat<params...> )
     }

      proxy<othercontract> prox(accountnum, sendernum = currentcontract() );
      auto result = prox.callme( .... )

Priv Contacts for Unit Tests
proxy prox(contractnum, sendernum);

React, React-DOM, and other packages that we currently dynamically pull in, should be deployed on-chain.

Untradeability is a pretty standard trait for a token to have, so it should be added to the base token contract as a property that a token can have.

When a token is untradeable, it:

• Cannot be credit to anyone, except by the owner of the token issuer NFT. This allows untradeable tokens to still be distributed, but prevents anyone from trading them.

In the initialization of the token contract, the system token should be made untradeable.