MetaGame is using Ceramic to store user profile information. Occasionally a user will have the account they used to create their profile compromised & will need to abandon it.
My understanding is the controller of a stream can’t be changed once it’s created & streams can’t be deleted. I can unpin a stream, so that hopefully its data will fade away, but that won’t remove it from the ComposeDB index correct?
I’m curious how you all would recommend dealing with a stream that is no longer wanted.
Hi @dysbulic
In your instance, are you finding that users are occasionally having their Eth accounts compromised? I’m assuming your users create profiles using did:pkh. Would love to hear more about how MetaGame underpins user identity if not with SIWE (I understand MetaGame also does things like calculate Github contributions/engagement, so perhaps you’re relying on platform sign-in for the remainder of your user identity logic?)
One option might be to have a profile model that has a subfield that is a relation to another model authored by the application’s server that would indicate whether or not the profile is valid for that user. You could then define a SET accountRelation to easily be able to tell which user profiles are valid and which ones are not (since the application could update the stream it made which is referenced in the profile document the user creates).
Alternatively (again, assuming your profile docs are authored by the did:pkh of your users), you could simply have 1 document your app server continuously updates as accounts are compromised. This would be cross-referenced by your app before pulling user profiles based on their did
We have definitely been thinking for a while about a feature for node operators to remove streams and/or events from their node that they do not wish to store and provide for any reason. It’s on our roadmap but not particularly high on it right now. I’d definitely be interested to hear how well workarounds like what Mark describes (where your application can filter these documents out from the UI, but the underlying data remains present on your node) work for you, vs whether you really need the actual data completely purged from the underlying node.