Creating big shared database
You should avoid duplicating rows in a database design.  You have a many-to-many relationship between events and users, so you will need the &quot;connection&quot; table between them to do that. There will be a one event to many connection relationship and one user to many connection relationship.
The connection table will have FK columns to both event and user, plus any attribute that is useful about that connection (e.g. visibility indicator, date accepted). Make the two FK columns be a unique constraint to make sure there are no duplicates.
You will need another table, perhaps named USER_EVENT_COMMENT, that will also FK to the user and event tables. You can either use an incrementing as a PK or combine the two FK columns with something else (perhaps a date) to make a composite PK. I think the auto increment approach is cleaner.
As to restricting the visibility of the comments, that depends on how you access the database from your application. If all access to the database is the same identity, then your application will need to enforce visibility. If you access with different identities, you can enforce visibility in the database.
As for size, a few billion rows is no big deal.  The proper indexes and thoughtful query construction (use bind variables) and you should be fine.