stop automatic grouping of repo events by identifer and
earliest unique commit into a single collection.
allow selection of different repos that have an
identifier collision by prioritising pubkey:identifier
over identifer
show repos grouped by name
maintain subscription after eose for most events.
User events excluded as to prevent maintaining connections
to too many relays.
fixes nostr:nevent1qqs83c56u0vvggqq8skve94u783v9r4nmh0xw32wta29rt3ge3d04dspp4mhxue69uhkummn9ekx7mqzyzsq3hh327t0h2dq6matqn5064cgj2zanl2stkj6s0lg4t2h5dty6hju4ax
store hexpubkey in Repo and Proposal data object
instead of full profile
this prevents unnecessary state updates for those objects
the trade-off is including business logic (getting profile data)
within UI components
this is mitigated by allowing hexpubkey or UserObject to be passed
to UI components so that UI component tests can be written without
having to worry about business logic
this new approach can be abstracted to other object types
some clients such as primal do not inherit the e 'root'
from the event they are replying to.
we therefore need to subscribe to all replies individually
to ensure we have the entire thread
this doesnt apply to subscriptions that we for many types simultainiously
ie repos and users
also extend limit from 50 to 100. if we need to go higher,
will we need to introduce a system to get around relay limits?
choose repo events based from earliest_unique_commit and indentifier
based on:
- number of mentions (issues and root patches)
- most recent created_at
identify repo events for the same repository based on identical identifiers
and use of earliest_unique_commit
use stores for collections of repo events
prevent bug where PR responses and summaries are added to an incorrect
pr or repo after the array has been cleared but before
ensureSelectedRepo has returned