Add communityMetadata store validation

[leblowl]

Only the owner should be able to update the community metadata. Currently anyone can modify the community metadata. This allows anyone to change the owner certificate (and nickname) and community name.

As an example, we replicate community metadata here:

quiet/packages/backend/src/nest/storage/storage.service.ts

Lines 244 to 248 in 277f966

	this.communityMetadata.events.on('replicated', async () => {
	this.logger('Replicated community metadata')
	// @ts-expect-error - OrbitDB's type declaration of `load` lacks 'options'
	await this.communityMetadata.load({ fetchEntryTimeout: 15000 })
	this.emit(StorageEvents.REPLICATED_COMMUNITY_METADATA, Object.values(this.communityMetadata.all)[0])

We save the metadata to the Redux store:

quiet/packages/state-manager/src/sagas/socket/startConnection/startConnection.saga.ts

Lines 263 to 271 in 277f966

	socket.on(SocketActionTypes.SAVE_COMMUNITY_METADATA, (payload: CommunityMetadata) => {
	console.log('SAVE COMMUNITY METADATA', payload)
	emit(
	communitiesActions.saveCommunityMetadata({
	rootCa: payload.rootCa,
	ownerCertificate: payload.ownerCertificate,
	})
	)
	})

We get the owner nickname from ownerCertficate:

quiet/packages/state-manager/src/sagas/communities/communities.selectors.ts

Line 78 in 277f966

export const ownerNickname = createSelector(

Which is used to send a channel message:

quiet/packages/state-manager/src/sagas/publicChannels/createGeneralChannel/sendInitialChannelMessage.saga.ts

Line 20 in 277f966

const ownerNickname = yield* select(communitiesSelectors.ownerNickname)

Another example, we set the community name from communityMetadata.rootCa:

quiet/packages/state-manager/src/sagas/communities/updateCommunity/updateCommunity.saga.ts

Line 6 in 277f966

export function* updateCommunitySaga(

which is displayed to the user in the left-side panel:

quiet/packages/desktop/src/renderer/components/Sidebar/IdentityPanel/IdentityPanel.tsx

Line 49 in 277f966

const communityName = currentCommunity?.name || '...'

[holmesworcester]

Whoever tackles this should dig into it a bit and write up a document proposing how to solve the problem and get feedback before they start writing code.

Part of the complexity is that you need to know the owner's OrbitDB ID or something about the owner to have some sense of truth here.

[leblowl]

In order to only allow the community owner to edit community metadata, we need to know if an entry was written by the community owner. To do this we can use the OrbitDB identity ID as OrbitDB uses to verify write permissions in OrbitDB's IPFSAccessController: https://github.com/orbitdb/orbit-db-access-controllers/blob/3741eb318e9c7efea5af15a54110cf6de8ae1fe3/src/access-controllers/ipfs.js#L20. Since each member of the community will need to know this ID in order to validate community metadata entries, we can simply include the community owner's OrbitDB identity ID in the invite link.

After the owner initializes their OrbitDB databases for the first time, we can save their identity ID (orbitdb.identity.id) in LevelDB under a key like ownerOrbitDbIdentityId. We can create a new file like src/nest/storage/identity.ts with functions for storing and retrieving the owner identity ID (putOwnerOrbitDbIdentityId, getOwnerOrbitDbIdentityId).

The owner's identity ID should be sent to the frontend for incorporating it into the invite link. In order to include the owner's OrbitDB identity ID and a PSK (#1897) in the link, we will need to reduce the number of peers in the invite link by 1. So PSK + owner OrbitDB identity ID + 3 peers.

When a new user clicks that link and joins, the owner's identity ID should be parsed from the invite link and sent to the backend where it's stored in LevelDB (via the same interface defined in src/nest/storage/identity.ts). This should happen before initializing any OrbitDB databases. Once the owner ID is stored, proceed to first initialize the community metadata DB.

The community metadata DB stores the owner's public key, which we use for authentication in some instances (e.g. when checking cert validity). So we should wait until community metadata has been replicated before initializing other OrbitDB databases (or at least those that depend on the owner's cert).

As for community metadata validation, it looks like access controllers only validate heads and not each entry. So instead of using an access controller, we can simply validate each entry ourselves. We can create a new validation function in the backend validateCommunityMetadataEntry that, given an entry, validates the entry by checking that the entry is valid, its identity signature is valid and the entry identity matches the owner and then also checking that the public key included in the community metadata payload is used to sign the community metadata payload.

In order to validate entries in an EventStore, it's fairly straightforward as discussed in #1893. However, communityMetadata is currently a key/value store. Since we don't support multiple communities yet, I'm not sure we benefit from using a key/value store in this case, but we can continue with that approach to reduce refactoring.

For KeyValueStore databases, the interface does not include an iterator method, so we can create our own KeyValueIndex (https://github.com/orbitdb/orbit-db-kvstore/blob/main/src/KeyValueIndex.js) class with a custom updateIndex method to filter log values with validateCommunityMetadataEntry before they are indexed. We can provide this modified Index class to the KeyValue store during instantiation. For an example, see: #1923

Then we can create a new function, getCommunityMetadata that simply retrieves the community metadata for a given community ID.

I think it would be nice to encapsulate this logic in a CommunityMetadataStore class.

[EmiM]

#2073

[kingalg]

2.0.3-alpha.15

Done