string interning? i don't know what this means. you mean the pubkey index? that's in there. yes, the pubkeys are encoded as 5 byte long pointers to the pubkey index. IIRC. i remember doing something with this. there is actually a table in there that links pubkey/event/kind together that theoretically should enable index free adjacency (meaning it only iterates one table to find the event or pubkey you seek).
haven't implemented it in many places yet but tag queries for e and p tags use it. it's potentially able to add a graph query language to walk that table
i'm implementing the change to a compact event format that exploits the pubkey, p and e tags being references. it also has a "placeholder" code for events that refer to events not yet in the database, these store the whole event id.
idk what to do about sharing the access to the relay, i think android has some features that would allow you to bind to the websocket listener and plug it into an IPC interface for other apps to also use, would require you to stipulate that the battery permissions on the app be active, so it could be a standalone service. idk about other users, since that rarely would be needed concurrently it can just be a startup service, like how orbot and wireguard work.
i'd put the encryption side of it at the OS level, just encrypt the whole app specific storage in the user's profile. storing drafts i think you could then eliminate the encryption step for when you are using the already encrypted db file storage area
as for the DMs storage, probably better to just put that in a separate place inside the encrypted file storage where the database engine reads and writes, so make two subfolders for that.
It just means that there is only one place in memory for all strings (or byte arrays if you convert them). So, all if,pubkey,p,e tags with the same value just point to the same address of the string/bytearray. It's like a huge KV db just for each string inside every nostr event.
