Community shares are published only to the sharer outbox — invisible on community relays #21

New issue

Closed

opened 2026-07-09 08:56:28 +00:00 by laoc · 2 comments

laoc commented

2026-07-09 08:56:28 +00:00

Owner

Found while verifying #8 with a real share (laoc42 sharing a 31922 event into a community).

createCommunityReposts publishes the kind 16 repost via publishEventOptimistic(signedEvent, communityPubkeys) with no communityEvent and no additionalRelays. The resulting relay set is: the sharer's outbox write relays + the tagged community pubkey's READ relays (communities usually have no kind 10002 → nothing) + app relays for kind 16 (none).

Verified on live relays: the repost exists on the sharer's personal relays (haven.laoc.xyz, theforest.nostr1.com) but NOT on relay.edufeed.org — so every community surface that reads from the communikey/edufeed relays cannot see the share. The UI still shows "(Shared)" from the optimistic local add.

Fix: include the communikey app relays and the target communities' own relays (from their kind 10222) in the repost publish.

Related UX defect (same dialog): the checkbox next to a community does not reflect the current shared state — a shared community shows "(Shared – click to unshare)" with an UNCHECKED box, because the checkbox encodes "pending change", not state. It should be checked when shared and toggle from there.

Found while verifying #8 with a real share (laoc42 sharing a 31922 event into a community). `createCommunityReposts` publishes the kind 16 repost via `publishEventOptimistic(signedEvent, communityPubkeys)` with no `communityEvent` and no `additionalRelays`. The resulting relay set is: the sharer's outbox write relays + the tagged community pubkey's READ relays (communities usually have no kind 10002 → nothing) + app relays for kind 16 (none). Verified on live relays: the repost exists on the sharer's personal relays (haven.laoc.xyz, theforest.nostr1.com) but NOT on relay.edufeed.org — so every community surface that reads from the communikey/edufeed relays cannot see the share. The UI still shows "(Shared)" from the optimistic local add. Fix: include the communikey app relays and the target communities' own relays (from their kind 10222) in the repost publish. Related UX defect (same dialog): the checkbox next to a community does not reflect the current shared state — a shared community shows "(Shared – click to unshare)" with an UNCHECKED box, because the checkbox encodes "pending change", not state. It should be checked when shared and toggle from there.

laoc added the

bug

label

2026-07-09 08:56:28 +00:00

laoc referenced this issue from a commit

2026-07-09 09:08:44 +00:00

fix(community): make shares reach community relays and community surfaces

laoc commented

2026-07-09 09:10:20 +00:00

Author

Owner

Fixed on branch fix/community-share-visibility (with unit tests, verified live on the reported share). Full causal chain of Steffen's report ("shared event only visible in the community calendar"):

Publish routing: the kind 16 went only to the sharer's outbox write relays (haven.laoc.xyz etc.) — never to relay.edufeed.org. Now reposts also publish to the communikey app relays, the shared kind's app relays and each target community's kind-10222 relays. The stranded original share was manually rebroadcast to relay.edufeed.org/relay-rpi.
Feed ranking: resolved shares inherit the ORIGINAL event's created_at, so a fresh share of an older event sank below the home feed's top-15 recency cut. Resolved items now carry _sharedAt (newest share time) and the feed ranks by activity time.
Upcoming events: were derived from the already-truncated top-15 feed. Now selected from the full access-filtered item set by start time.
Calendar durability: the community calendar never loaded kind 6/16 from relays (same-session store hits only). loadByCommunity now fetches h-tagged reposts and resolves their referenced events, so shares survive reloads and appear for other members.
Checkbox UX (from the report): not intended — the box encoded "pending action" instead of state. Shared communities now render checked; toggling shows "will be shared/unshared" as before.

Verified anonymously on a fresh load of the community page: the shared hackathOERn event now appears in Recent Activity and Upcoming Events.

Fixed on branch `fix/community-share-visibility` (with unit tests, verified live on the reported share). Full causal chain of Steffen's report ("shared event only visible in the community calendar"): 1. **Publish routing:** the kind 16 went only to the sharer's outbox write relays (haven.laoc.xyz etc.) — never to relay.edufeed.org. Now reposts also publish to the communikey app relays, the shared kind's app relays and each target community's kind-10222 relays. The stranded original share was manually rebroadcast to relay.edufeed.org/relay-rpi. 2. **Feed ranking:** resolved shares inherit the ORIGINAL event's `created_at`, so a fresh share of an older event sank below the home feed's top-15 recency cut. Resolved items now carry `_sharedAt` (newest share time) and the feed ranks by activity time. 3. **Upcoming events:** were derived from the already-truncated top-15 feed. Now selected from the full access-filtered item set by start time. 4. **Calendar durability:** the community calendar never loaded kind 6/16 from relays (same-session store hits only). `loadByCommunity` now fetches h-tagged reposts and resolves their referenced events, so shares survive reloads and appear for other members. 5. **Checkbox UX (from the report):** not intended — the box encoded "pending action" instead of state. Shared communities now render checked; toggling shows "will be shared/unshared" as before. Verified anonymously on a fresh load of the community page: the shared hackathOERn event now appears in Recent Activity and Upcoming Events.

laoc referenced this issue

2026-07-09 09:10:20 +00:00

After editing a calendar event, community selection is lost and must be re-selected #8

laoc referenced this issue

2026-07-09 09:21:11 +00:00

After editing a calendar event, community selection is lost and must be re-selected #8

laoc commented

2026-07-09 09:21:11 +00:00

Author

Owner

Confirmed via the #8 retest. Merged to dev.

laoc closed this issue