Questions

[Mookse]

Question Objects/Processes

• question.json: when creating question object
  • scope: oneOf ["universal", "global", "public", "private", ] (listed in terms of ubiquity, see notes)
  • purpose:
• $def/question_response: responses need to be archived independently unfortunately, but would be stored under the members id, as they are affiliated with it; don't anticipate managing a separate class yet
• class-extenders.mjs
  • create question extension class
  • create response object and save to db
• server.js
  • MyLifeMemberSession.getQuestionsUniversal(): upon session creation or member login version of init():
    • check MyLifeMemberSession.questions for universal questions
      • true: ctx.state.universalQuestions array
        • retrieves list of universals, random scatters?, takes [0]
      • false: void
      • version guest
        • universal answers for now are only relevant at the session level (every browser restart restarts) however, we could store qid and state in cookies so at least browser knows
      • version member
        • store response for now directly inside the root question object [responses array] but this will cause me to start thinking about the best way to implement iterators given a NoSQL
      • notes: no additional sorting or filtering required as of yet, but this would be one hook for parsing (i.e., stagger questions if more than one)
• session.js
  • init()
    • getQuestionsUniversal(): returns {array} | queries Maht for universal questions
    • store in property .questions array
• functions.js, routes.mjs: provide access points for displaying questions; note that all of the scopes presume visitor except for private, which indicates they will be operating on their affiliate questions
  • getQuestions(): gets all question-types (up to max) that user may engage with that they themselves are not parent
    • sorted by scope desc [currently just based on index]
  • getQuestionsUniversal(): gets universal questions
  • getQuestionsGlobal(): gets global questions [member-only]
  • getQuestionsRelations(_type='known'): start with full list, but can winnow down either on front-end or with
    • consent object would rely on relations array(s)
  • getQuestionsPrivate(): returns member-parented questions
• index.html, 'members.html', 'sidebar-universal-questions.html'
  • logic to display question(s) bubbles or widgets, capture and post response, self-morph upon receipt
• core.mjs
  • Member objects should be spawned with their own questions populated at least by id in this.#questions
  • any core should be able to have this, but for now, focus on Core... and in what ways are these different from registration/signup questions?

Question Scopes:

• Universal: The explanation remains relevant and is always requested by the member until it's answered.
• Global: The information is accessible publicly and pushed to the global queue for broader access.
• Public: The content is findable by any browser, making it widely available.
• Relational: Intended for Member-Only access or a specific subset of members. This requires an intelligent interpretation to cater to either all members or a selected group.
• Private: The information is exclusively available to the associated member.

This system reflects MyLife's commitment to digital privacy and personalized experience, allowing members to choose how their stories and memories are shared and accessed within the platform.

notes

assistant-related

• getQuetsionsRelational is not a cakewalk, it would require a consultation for known relations, ergo, one of the avatar's first functions (maybe a lot of these will get translated to functions as we go along, so that the OpenAI assistant can make logical calls (obv ending up going through a consent filter) to MyLife API functionality

consent-related

• manages core object data alteration, i.e., storing that question was answered
• consent_setting: attach node literal to object (not strictly required yet, still working out kinks, but premise is that if exists, provides direct additional annotation to consent that is durable, since consent objects are ephemeral); could add this to context, but simple enough to partition, seems preferable at moment. Additionally, it could ultimately get crafted inside of object.settings once we have a settings assistant in place, but not knowing it's full functionality, this is the best first stab

question-related

• todo: implement required functionality
• determining scope of question from member is created or updated, could lead me to the right answer for a consent object, and how to populate. When someone creates a question, they have a scope dropdown (of course, could be typed in also, but there is still room for interfaces when dialog is NOT required or preferred, like the difference between texting and calling)
  • if Members/Membership is selected, relational is the type
    • consent object would force push (comes later, but utilize pipeline, just no await for now)
    • member would be displayed (pre-populated?) input box to describe who should be able to see this - my family, etc
    • that response data gets piped to question to submit to consent object (and presumedly if true, stored for user in core or settings, but that hasn't been developed yet, so just pass-through)
  • when visiting Member site other than self, this question list would be populated according to the visited Member's list prepared for the public, or run through the relational consent matrix; while the bot at some point should be able to manage,
  • it's funny to think of a set of nested complexities around consent... i.e., must have professional working knowledge of physics, and Member would be inclined to point to second question, like one that would "prove" to the member/avatar that the visitor had the chops, but then it might lead down an endless path of interrogationing

[Mookse]

Whether or not that is exact architecture, system avatar and member avatar should have ability. Collection should be assigned to avatar