docs(commons): repoint KDoc links that still named app-module classes

The relay-group, connected-apps and poll-responses files moved into commons
still linked to classes by their old amethyst paths (or to app-only screens
commons cannot see). Point them at the commons class where one exists and
use plain text where the target stays in the app.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J836W9ZjSUJUQ1d23TpiJo
This commit is contained in:
Claude
2026-09-05 22:52:13 +00:00
parent 58ada4e32e
commit fe81faef7e
5 changed files with 6 additions and 8 deletions
@@ -37,7 +37,7 @@ import com.vitorpamplona.quartz.nip01Core.relay.client.pool.RelayBasedFilter
* The 39000-39003 metadata block and the 39005 pin list go out as **two separate filters**: relay29-family
* relays (0xchat's included) reject a filter that mixes them and drop the whole REQ, which would leave the
* group with no name, no roster and no membership. See
* [com.vitorpamplona.amethyst.ui.screen.loggedIn.chats.publicChannels.relayGroup.datasource.RELAY_GROUP_PIN_KINDS].
* [RELAY_GROUP_PIN_KINDS].
*/
fun filterRelayGroupState(
channel: RelayGroupChannel,
@@ -33,8 +33,7 @@ import com.vitorpamplona.quartz.nip29RelayGroups.metadata.GroupMetadataEvent
* the people dimension (relay-key follow / follow-is-admin / follow-is-member) can't be expressed
* as an `authors` REQ. For Global and the people filters we therefore pull the whole directory
* (metadata + rosters) for each relay in the resolved set and let
* [com.vitorpamplona.amethyst.ui.screen.loggedIn.chats.publicChannels.relayGroup.dal.RelayGroupDiscoveryFeedFilter]
* narrow it locally. Only the topic/geo filters ([filterRelayGroupsByHashtag]/[filterRelayGroupsByGeohashes])
* the app's `RelayGroupDiscoveryFeedFilter` narrow it locally. Only the topic/geo filters ([filterRelayGroupsByHashtag]/[filterRelayGroupsByGeohashes])
* carry a real relay-side constraint.
*/
val RELAY_GROUP_DISCOVERY_KINDS =
@@ -346,7 +346,7 @@ fun buildRelayGroupJoinedChatTailFilter(
*
* Every other roster-driven protocol on that screen already bounds by count for exactly this reason:
* NIP-28 asks `limit = 1` per followed channel
* ([com.vitorpamplona.amethyst.ui.screen.loggedIn.chats.rooms.datasource.filterLastMessageFollowingPublicChats]),
* (the app's `filterLastMessageFollowingPublicChats`),
* Concord asks `limit = 10` per channel with no floor (`ConcordSubscriptionPlanner.channelPreviewFilters`).
* They can, because their row set comes from a list event — unlike NIP-17/NIP-04, whose *rooms* are
* discovered from the messages themselves and therefore need the backward pagers on the Messages list.
@@ -24,7 +24,6 @@ import androidx.compose.runtime.Stable
import com.vitorpamplona.amethyst.commons.model.IAccount
import com.vitorpamplona.amethyst.commons.relayClient.AccountScopedQuery
import com.vitorpamplona.amethyst.commons.relayClient.composeSubscriptionManagers.ComposeSubscriptionManager
import com.vitorpamplona.amethyst.commons.relayClient.napplets.NappletsFilterAssembler
import com.vitorpamplona.quartz.nip01Core.core.HexKey
import com.vitorpamplona.quartz.nip01Core.relay.client.INostrClient
import com.vitorpamplona.quartz.nip01Core.relay.normalizer.NormalizedRelayUrl
@@ -44,8 +43,8 @@ class ConnectedAppsQueryState(
) : AccountScopedQuery
/**
* Live subscription for NIP-5D napplet manifests (kinds 15129/35129) while
* [com.vitorpamplona.amethyst.ui.screen.loggedIn.napplets.ConnectedAppsScreen] is open.
* Live subscription for NIP-5D napplet manifests (kinds 15129/35129) while the connected-apps
* screen is open.
* Unlike [NappletsFilterAssembler] (which follows the global follow list), this assembler
* only fetches manifests for the specific authors that have entries in the permission ledger.
*/
@@ -44,7 +44,7 @@ class PollResponsesQueryState(
* The screen already gets the poll's own engagement through the shared event watcher; this adds the
* one thing that watcher cannot give it — a page of votes big enough to be worth calling "every
* voter", drawn from the poll's declared relays. Structured like every other current-screen data
* source ([com.vitorpamplona.amethyst.ui.screen.loggedIn.threadview.datasources.ThreadFilterAssembler]
* source ([com.vitorpamplona.amethyst.commons.relayClient.thread.ThreadFilterAssembler]
* is the closest sibling) so it is lifecycle-aware, deduplicated across screens, and EOSE-tracked
* without any of that being written twice.
*/