import 'offer.dart';

/// The abstraction the plan promises lives in `commons_core` (core-domain-
/// boundary.md §2, PLAN §4): publish an [Offer], discover offers by area. The
/// concrete Nostr NIP-99 backend sits behind this so the domain never talks to
/// a relay directly, and a second backend (ActivityPub / FEP-0837) could slot
/// in without the app noticing.
///
/// Spike Question 2 asks whether messaging (NIP-17) and trust (NIP-85) fit
/// behind this same seam, or whether they couple more than the plan implies.
/// The finding: they do NOT belong here — they share the *key* and the *relay
/// connection*, but their verbs differ (send/receive a private DM; assert/read
/// a certification). Forcing them behind `OfferTransport` would overload it.
/// See spike-block2-findings.md §2 for the proposed 3-interface split over one
/// shared `NostrConnection`.
abstract interface class OfferTransport {
  /// Publishes (or replaces) [offer]. Idempotent on the offer id.
  Future<PublishResult> publish(Offer offer);

  /// Streams offers matching [query]. Emits already-stored matches, then live
  /// ones as they arrive, until the caller cancels the subscription.
  Stream<Offer> discover(DiscoveryQuery query);

  /// Retracts a previously published offer (NIP-99: publish a `closed` status /
  /// NIP-09 deletion). Relays that already replicated it drop it over time.
  Future<void> retract(String offerId);

  Future<void> close();
}