[Feature] Add native Nostr protocol support in Flare, enabling users to publish and consume content via Nostr relays

[Rsync25]

Proposal

Add native Nostr protocol support in Flare, enabling users to publish and consume content via Nostr relays.

Motivation

Flare currently aggregates feeds from platforms such as Mastodon, Bluesky, Misskey, X, and RSS. By integrating Nostr, Flare can:

• Connect to a growing decentralized pub-sub ecosystem.
• Allow users to post and consume Nostr content (events, reactions, zaps) alongside existing federated feeds.
• Provide cross-protocol interoperability, enabling shared posting and multi-client access.

Suggested Features

1. Relay connection

   • Connect to public or user-specified Nostr relays
   • Subscribe to event kinds such as notes, reactions, and metadata

2. Publishing

   • Support publishing Nostr Kind 1 (text), Kind 42 (long-form), and video-related NIPs relevant to Flare’s video features

3. Interactions

   • Enable liking, zapping, and replying using standard Nostr event kinds and NIPs (e.g., NIP-25 replies, NIP-65 zaps)

4. UI integration

   • Add Nostr feed timelines and publishing forms consistent with existing interfaces

5. Account onboarding

   • Provide sign-in via NIP-07 or NIP-46 and local private key management

Benefits

• Expands Flare’s reach into the decentralized content network.
• Enables seamless cross-client publishing and feed aggregation.
• Aligns with existing video-centric use cases (e.g., Flare’s support for Nostr video events).

Considerations

• Should Nostr integration be enabled by default or remain opt-in?
• How to handle relay discovery, selection, and moderation?
• Should user-hosted relays be supported in addition to public ones?
• What moderation policies or filters should be applied?

References

• [Nostr protocol specifications and NIPs]
• Existing Nostr video event implementations relevant to Flare

[Tlaster]

I’d love to integrate Nostr into Flare!
In fact, during the early stage of the Flare project, I did some research on Nostr.
Compared to traditional Web2 social networks, integrating Nostr is relatively complex since Flare has to handle more things locally, so it hasn’t been included in the short-term plan.

However, with projects like rust-nostr/nostr-sdk-ffi now available, I think I can give Nostr integration another try after the iOS version officially launches (estimated in about 2–4 months).

If anyone is interested in helping with the integration, we could even move this timeline forward to an earlier point.

[Rsync25]

@Tlaster this is an awesome news! I know Nostr is a complex system. I can help too!

[Tlaster]

Thanks! Here’s a high-level outline for adding Nostr (or any social platform) to Flare:

• Single source of truth

  • Flare follows a single source of truth principle. State changes (e.g., like/boost status) should be persisted via the database first, and the UI reflects the DB.

• Declare the platform

  • Add entries for the new platform in:
    • dev.dimension.flare.model.PlatformType
    • dev.dimension.flare.ui.model.UiApplication
    • dev.dimension.flare.ui.model.UiAccount

• Network layer

  • Under shared/src/commonMain/kotlin/dev/dimension/flare/data/network, add the platform’s API calls.
  • If possible, use Flare’s built-in dev.dimension.flare.data.network.ktorClient as the httpClient.

• DataSource layer

  • Under shared/src/commonMain/kotlin/dev/dimension/flare/data/datasource, add a DataSource that implements:
    • dev.dimension.flare.data.datasource.microblog.AuthenticatedMicroblogDataSource
  • For the timelines, you’ll implement either:
    • BaseTimelineRemoteMediator — for feed-like sources (e.g., home timeline). These are cached in Flare’s DB.
      • DB cache types: Provide concrete types for:
        • dev.dimension.flare.data.database.cache.model.StatusContent
        • dev.dimension.flare.data.database.cache.model.UserContent
      • Model mapping:
        • Add mappings in:
          • shared/src/commonMain/kotlin/dev/dimension/flare/ui/model/mapper/Render.kt
          • shared/src/commonMain/kotlin/dev/dimension/flare/data/database/cache/mapper/
        • Use the existing Mastodon.kt (same directories) as a reference for mapping style.
      • Events:
        • Implement dev.dimension.flare.data.datasource.microblog.StatusEvent for your source and handle the relevant events.
    • BasePagingSource — for non-cached, arbitrary lists (e.g., followers).
      • Return types should come from dev.dimension.flare.ui.model (e.g., dev.dimension.flare.ui.model.UiUser).
  • For single entiry, you'll need to use dev.dimension.flare.common.Cacheable or dev.dimension.flare.common.MemCacheable, you can take the usage in MastodonDataSource as example.

• compose-ui tabs

  • In compose-ui/src/commonMain/kotlin/dev/dimension/flare/data/model/TabSettings.kt, add the tabs supported by this platform.
    • Apologies that this file is a bit messy; in practice you mainly need to fill in:
      • defaultPrimary
      • defaultSecondary
      • secondaryFor

Adding a new social platform to Flare is currently a bit verbose and some steps are repetitive. In the (far) future I'll consider a plugin-style architecture to streamline this, but I don’t have bandwidth for that right now.

If you’re up for it, we can integrate Nostr step by step following the plan above. I’m happy to review PRs and pair on any of the pieces.

[Rsync25]

Sounds good solid plan

[Rsync25]

If you’re up for it, we can integrate Nostr step by step following the plan above. I’m happy to review PRs and pair on any of the pieces.

I'm all in!

[Rsync25]

@Tlaster I will prepare this week, the first PR or if you want you can do it too

[Tlaster]

@Tlaster I will prepare this week, the first PR or if you want you can do it too

Thanks a lot! Right now I’m mainly focusing on the iOS version and fixing bugs in the existing releases, so I don’t really have time to work on Nostr integration at the moment.

But there’s no rush, feel free to take your time, and I’ll be happy to review and support when you’re ready.