Alpha Release Final Sprint

[Mookse]

• basic login fixed
• challenge logic re-routed
• avatar construction-logic
  • define minimal data requirements for avatar creation (see appropriate comment)
  • sign-up routine?
  • develop first consent object
    • create consent.json
    • assign unique functionalities in factory
      • allow()
        • currently returns simple boolean
    • Class extenders refactor #98
    • all consent objects instantiated by factory will be reported to session
      • special case: no getters/setters for this.consent in factory
      • instantiate through async factory function getConsent(_consent_id)
    • consent array will persist in session memory in this.#consents
    • insert object on access actions inside of factory
    • will function generally as pass-through/storage of permissions/consents for pre-alpha
    • capture e-signature for member, and contain basic system info on MyLife Membership such as license, code of conduct, etc.
    • note: consent objects are never exposed directly to anyone for modification except owning mbr_id for now; additionally, other than during configuration, they are not accessible to anything but the MyLife platform, they are always "behind-the-scenes" cartilage between objects/entities
  • populate
    • instructions: what parameters can define what to populate? Work with Maht to work up appropriate number of sentences and how to influence tone effectively (perhaps through chat samples as next describes?)
    • as example, categories should exist as metadata and their usage explained in instructions
  • create master file that outlines MyLife Membership and will be attached (with tool retrieval) to every
  • upload (to all familiar destinations) a file of historical member chats (when existing) and attach to agent build
• avatar context-awareness #101
• avatar management/personae #106
  • be able to see the avatars that are assigned and constructed for various objects - avatars that represent cores are called personae (in front-end vernacular, back-end exists only as query for avatars against mbr_id_id as parent_id)
• evo-agent upgrade v1.1 #107
• Questions #108
• member-browser for logged in entities
  • protect with message?
  • change url exposure (obfuscate) for board examples?
• member-controlled (frontend interface) object build (outline both innate (i.e., system built based on how member uses system opposite user-defined; both triggered by interface usage)
  • Core objects are reserved for members/MyLife, but anything can have an avatar that is not an avatar
  • Do agents need to be stored in Cosmos right away, or best left until having prove themselves in testing, i.e., they conduct enough activity to get saved
  • This is likely tied to the capacity to "build" objects (superintelligent or not) of any ilk
  • thinking of several levels: unintelligent bean objects(user?system?)? cosmos objects (user-built)? structural enhancements (member-built in source code)? Ecosystem plugins (partner objects by reference)? Eco-system objects (outsource?)?
    • who is able to "make" and/or "authorize" such objects. those I personally am familiar with? have shared with? [managed by consent, but here is example in action] -- objects coming up in generalized search for content/concepts/people/ideas
• signup
  • incorporate age-range
• incorporate age/age range

[Mookse]

• define minimal data requirements for avatar creation

required

properties

• core in Cosmos
  • currently, we would "hand draw" these as members are selected for alpha; presuming that should change in the near future, I imagine something like a quick sign-up via chatbot (and include Sam's ONE question all members have in common the act of answering: (what's one thing you would change?) How would you make the world a better place for all?)
  • given that aside from permission, we don't need anything else, here's the outline of required fields for human core
    • categories
    • language
    • "username"
      • populates name, names[0], and first half of mbr_id (sysname)
    • passphrase secret
    • email
      • if unwilling to answer: defaults to [sysname|(first bank of guid)]@mylife.org

permissions

membership account level

• build baby's first consent object, even if it is not yet superintelligent and functions only as pass-through