Enhancing Request/Offer Interaction Flow

[Soushi888]

Goal: To improve the flexibility, clarity, and targeting capabilities of the Request and Offer features within the application.

Context: Currently, Requests (hREA Intents) and Offers (hREA Proposals) are created by users, can be associated with organizations, and are generally discoverable via global anchors (AllRequests/AllOffers). While functional, we could enhance the interaction flow to support more direct and nuanced exchanges.

Proposed Enhancements:

1. Initial Targeting & Visibility Options:

   • Suggestion: When creating a Request or Offer, allow users to choose:
     • Public (Generic): Visible to everyone, no specific targets initially.
     • Targeted: Visible only to one or more specific Users/Organizations initially (inherently private).
   • Rationale: Simplifies the initial user choice to broadcasting publicly or sending directly/privately.
   • Implementation Notes: Requires a visibility flag (public or private/targeted) and target links. Public items use global anchors; Targeted items might use direct messages/links or specific targeted anchors.

2. Retain Generic Requests/Offers:

   • Suggestion: Ensure the current functionality of creating generic, non-targeted Requests/Offers remains.
   • Rationale: Essential for broadcasting general needs or availability to the wider community.

3. Dynamic Targeting & Visibility Changes (Post-Creation):

   • Suggestion: Allow users to modify existing Requests/Offers:
     • Manage Targets: Add or remove specific User/Organization targets to a Public item (implicitly making it visible to targets and publicly discoverable). Add/remove targets from a Targeted item (remains private).
     • Make Public: Add an explicit action to convert a Targeted item to be publicly discoverable (while retaining targets).
     • Make Private: Add an explicit action to make a Public item (that has targets) visible only to its current targets.
   • Rationale: Provides flexibility post-creation while maintaining a simpler initial model. Explicit actions for changing visibility enhance clarity.
   • Implementation Notes: Requires coordinator zome functions for adding/removing target links and updating visibility flags/anchor usage. Needs careful state management and clear UI representation (e.g., distinct icons/labels for Public, Targeted-Private, Targeted-Public states).

4. Formalized & Unified Closure States:

   • Suggestion: Clearly define and implement "closed" states (e.g., fulfilled, cancelled, expired) for Requests and Offers. When an item enters a closed state, it should prevent further interaction for everyone, including specific targets and those discovering it generically.
   • Rationale: Improves clarity on item status and prevents unnecessary actions on concluded exchanges.
   • Implementation Notes: Leverage hREA process states (Completed, Canceled). Consider adding Expired. The closure must apply universally to the specific Request/Offer instance. UI should reflect this and disable actions.
     • Intermediate State: Consider an explicit "In Progress" or "Accepted" state after mutual agreement (e.g., Offer accepted for a Request, forming an hREA Commitment) but before final completion. This state signifies the work/exchange is underway.
     • Post-Completion: Following a Completed state, implement a mechanism for mutual validation by both parties confirming satisfaction. Include options for public reviews and structured feedback (e.g., on time, as agreed, rating). Plan for admin-mediated dispute resolution if validation fails or issues arise.

5. Cloning Functionality & Independence:

   • Suggestion: Add a "Clone" button/function for existing Requests and Offers.
   • Rationale: Provides a quick way for users to duplicate items. Importantly, clones are distinct new instances; closing or modifying the original Request/Offer will not affect its clones.
   • Implementation Notes: Utility function in coordinator zomes and UI action. Ensure new, unique identifiers for clones.

Discussion Points:

1. hREA/ValueFlows Alignment: How do the proposed enhancements—specifically multi-targeting, dynamic visibility control, and the refined state model (Open -> Accepted/In Progress -> Completed -> Validated/Reviewed, plus Cancelled/Expired)—align with established ValueFlows patterns and best practices for hREA implementation? Are there more idiomatic ways to model these interactions using Intents, Proposals, Commitments, and Process specifications?

2. State Model & Lifecycle: Does the proposed state lifecycle adequately capture the necessary steps for managing requests and offers within the hAppenings context? Are there potential edge cases or alternative transitions we should consider (e.g., re-opening, partial completion)?

3. User Experience (UI/UX): How can the interface clearly communicate:

   • The distinction between Public and Targeted items?
   • The ability to add targets or change the visibility (Public/Private) of an item?
   • The current state of an exchange (Open, In Progress, Needs Validation, Completed, etc.)?

4. Technical Implementation Strategy: What are the key technical decisions needed for:

   • Zomes: Efficiently handling potential multiple target links? Implementing the state machines and validation logic?
   • Service Layer: Designing the Effect TS flows for these potentially more complex interactions?
   • Data Mapping: Ensuring hREA data is correctly mapped for UI presentation across these different states and types?

5. Feasibility & Prioritization: Considering the technical complexity and user value, which of these proposed enhancements should be prioritized for the next development cycle? Are there simpler intermediate steps we could take?

Let's discuss the feasibility and priority of these enhancements.