Meteor publication limit and skip pagination with missing server-enforced max

Meteor publications are reactive Mongo cursors. The server sends matching documents to client Minimongo unless the publish function explicitly constrains the cursor with limit, skip, fields and a user scoped selector.

Paginating a large collection is developer implemented via limit and skip in publish options or via methods returning pages. There is no framework provided cursor based pagination primitive, and bounding a query relies entirely on the developer to constrain selector, fields and options. The framework does not automatically bound results or enforce row level access control.

An unresolved design decision is how to enforce a server side maximum limit per publication and a per user permission boundary when the framework does not require it. Accidental unbounded publications can sync an entire collection, and reactive skip/limit degrades with large offsets as Mongo must scan skipped documents and reactive update work grows with collection size and change volume.

What server side mechanism should enforce a per publication maximum limit? How should per user permission boundaries be expressed for paginated selectors? Is skip/limit pagination acceptable for large offsets given reactive update cost?