Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
biboumi
biboumi
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 88
    • Issues 88
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 7
    • Merge Requests 7
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • louiz’
  • biboumibiboumi
  • Issues
  • #3314

Closed
Open
Opened Nov 11, 2017 by Romain DEP.@rom1depContributor

Make biboumi aware of "public" chanels and for these, don't duplicate message archive for each user

Some use cases involving many users connected simultaneously to a same room end-up with the message archive exploding in size (due to n-plication, for n-connected users).

It would be nice if biboumi could be taught about the public nature of a room so it could log it consistently in a single, consolidated place (reducing the archive size and load for message retrieval).

The following few concerns have been voiced:

  • moderation of what a user can see (i.e. after kick/ban or before initial join) → here we assume that the chan is public (no message is secret), and MAM should be served to its full extent, with no consideration for the user presence or history in the room
  • ownership of the "public" attribute → it is up to the transport admin to switch the knob, this setting isn't really relevant to the transport user
  • presence in the room when no user is present → a "biboumi" room user could be considered, alternatively, losing message archive when no user is present shuold be an acceptable trade-off
  • incoming messages de-nplication → n concurrently connected users would mean biboumi seeing the same message arriving n-times (or less) with in a short time-span. A strategy needs to be implemented to merge these into a single entry in the message archive (content is expected to be the same, except for the timestamp part, so a buffer few seconds-long for duplicates detection, based on the message content, may work in practice?)
Edited Nov 11, 2017 by Romain DEP.
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: louiz/biboumi#3314