WIP book.gno

[jaekwon]

This is a concept for a book (basically a list).
A Book has a title, owner, etc.
A Book can be forked.
Books can be components of a virtual Person (where a Person is an interface).

TODO: maybe I should move these experiments to another repo.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (b34816b) 47.82% compared to head (62b9196) 48.08%.
Report is 60 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1224      +/-   ##
==========================================
+ Coverage   47.82%   48.08%   +0.26%     
==========================================
  Files         369      368       -1     
  Lines       62710    62566     -144     
==========================================
+ Hits        29992    30086      +94     
+ Misses      30295    30054     -241     
- Partials     2423     2426       +3     

see 43 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[moul]

TODO: maybe I should move these experiments to another repo.

It's up to you, but you're welcome to stay here. We're increasingly allowing "personal realms" in the repository, as mentioned in issue #1138.

I believe it's logical to keep most of the experiments, such as Carmel, books, Wikipedia, etc., in this repository by default. We can consider making them more autonomous to reduce noise, like when we have multiple pull requests.

Up to you!

[jaekwon]

manfred also mentioned #1244

[jaekwon]

Also see #1244 (comment)

func (book Book) Execute(action Action) error {
    // makes sure the action signatures, sequence, etc are valid.
    if err != book.Owner.Append(action); err != nil {
        return err
    }
    // the logic below could use permissions if it wanted to, or not.
    switch action.(type) {
    case: WriteAction:
    case: ReadAction:
    default: return UnrecognizedError()
    }
}

As long as it's assumed that the action will complete in one transaction, this is fine; although we are also assuming that the programmer programs such that ultimately there is a panic upon some error.

Or maybe this is desired sometimes:

func (book Book) Execute(action Action) error {
    // makes sure the action signatures, sequence, etc are valid.
    x, err := book.Owner.Reserve(action)
    if err != nil { 
        return err
    }
    // the logic below could use permissions if it wanted to, or not.
    switch action.(type) {
    case: WriteAction:
    case: ReadAction:
    default: return UnrecognizedError()
    }
    // signal that the execution reserved is complete.
    x.Done()
}

Or javascript closure like:

func (book Book) Execute(action Action) error {
    // first reserves, or panics if error
    book.Owner.Execute(action, func() {
        // if reservation was complete:
        // the logic below could use permissions if it wanted to, or not.
        switch action.(type) {
        case: WriteAction:
        case: ReadAction:
        default: return UnrecognizedError()
        }
    });
}

which feels wrong.

---

Some thoughts on Action...

// object has an action verb (method), which takes arguments
type Action struct {
    subject // is this an id? 
    verb // i guess a string or Name type?
    object // is this an id?
    arguments // are these primitive strings or any
}

// Authorization struct is only needed for Actions that require
// cryptographic authorization, where the Action's subject has
// a pubkey to verify signatures with.
//
// Presumably once Authorization is validated (signature checked)
// the Action becomes committed, and given a index number.
type Authorization struct {
    action Action
    signatures []Signature
}

type Signature struct {
    account number // or address with some extra data unknown
    sequence number // or alternative to sequence
    signature []byte
}

Msg:Tx :: Action:Authorization here, except

type Msg interface {
        Route() string
        Type() string
        ValidateBasic() error
        GetSignBytes() []byte
        GetSigners() []crypto.Address
}
type Tx struct {
        Msgs []Msg
        Fee Fee
        Signatures []Signature
        Memo string
}

Interesting correspondences

• Action.subject corresponds to Msg.Route
• Action.verb corresponds to Msg.Type
• Action.object and Action.arguments are in the concrete fields of the Msg
• Authorization.Signatures[].sequence and .account included for client convenience (optional?)

[moul]

Yes, we need an equivalent of std.Address specifically for objects. The directory will function as the object catalog, similar to how the tm2 account module handles key-based accounts.

[netlify]

❌ Deploy Preview for gno-docs2 failed.

Name	Link
🔨 Latest commit	62b9196
🔍 Latest deploy log	https://app.netlify.com/sites/gno-docs2/deploys/65519a26eee9dc0008654f34