The problem Ylide - P2P File Communication platform solves

The P2P File Communication Platform allows for the following functionalities:

Generating and Registering the Communication Keys: As Ylide SDK requires a KeyPair to work with message encryption and decryption, the platform takes care of exposing this functionality for the end users. First-time users can generate and register their communication keys with Ylide and start sending secure communications.

Creating a private Room: The platform allows creating of a private room with a set of recipient addresses by any user. This room can then be used to send unidirectional information from the creator to the list of recipient addresses defined during the room creation. Both the creation of the room and the sending of messages to the room recipients are encrypted and secure in every way.

Seeing My Room list: The platform shows a list of private rooms a user is part of, once the onboarding has been completed.

See Messages & Files of My Rooms: The platform shows a list of messages received in a room, given that the user is present in the room recipient list. The messages are decoded and decrypted using the user's communication keys, so the messages are only visible if the onboarded user is present in the room recipient list.

Send Messages & Files to a Room: [Admin-only Action] Since the platform supports only unidirectional messaging, the room's creator can send encrypted/private messages to all recipients of the room, which are then decoded on the receiver's end.

Using IPFS with Infura for storing files on-chain.

Challenges I ran into

One of the first problems you face when working with an event history retrieval in EVM — is the inability of most RPC nodes to filter the events' history properly. eth_getLogs allows you to retrieve events only in ascending order, and all the public RPC nodes have limitations over the number of blocks you can scan at once.
It causes a huge problem when you want to perform a simple task such as "retrieve the last ten events". In general, you will have to backwards-traverse all the blockchain history until you find the first ten events. The dramatic downside of this problem is that having limits for the scanned block count of the public RPC nodes means that you will have to make hundreds or even thousands of queries until extracting these events. Moreover, users will have to wait minutes to see their last ten messages. The "good news" is that you will never have such a problem: any public RPC node bans you after the first hundred such queries, and your user will just close the dApp.
We figured out how to optimize such queries drastically.
First of all, we have to store the information about the last X messages for certain recipients in our smart contracts. Secondly, we have to optimize our smart contract execution as much as possible to reduce gas costs since executing anything inside the smart contract is very expensive.