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
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
- update repo event maintainers format to reflect model used for
multiple entries for a single tag used in nip34
- show all users claiming to be a maintainer of identifier on homepage
- update repo event tags to reflect nip34
- refactor: move RepoSummary interface and default into type.ts
the notable visible change is to use `clone` tag in place of
`git_server`
non-nip34 tags are supported: `unique_commit` and `maintainers`.
these enable desirable functionality to be maintained.
Silberengel
DanConwayDev
jk