Most applications need to have a concept of who the current user is.
So Jifty supports this concept internally.
Every Jifty::Object (which most things in Jifty are descended from) except the CurrentUser itself is instantiated with a Jifty::CurrentUser subclass as a parameter to the creator.

This class describes (and implements a trivial version) of the access control API that a Jifty application needs to implement to provide user-based access control

It's generally expected that your application will override this class if you want any sort of access control.

Every class in a Jifty application has a "current_user" method that returns the user who's doing things, in the form of a Jifty::CurrentUser object a subclass thereof. For the somewhat obvious reason that you can't actually lift yourself up by tugging on your own bootstraps, a Jifty::CurrentUser object return itself rather than another Jifty::CurrentUser object

Sometimes, while the system is running, you need to do something on behalf of a user that they shouldn't be able to do themselves. Maybe you need to let a new user sign up for your service (You don't want to let any user create more users, right?) or to write an entry to a changelog. If the user has the is_superuser flag set, things still get read from the database, but the user can walk around any and all ACL checks. Think "Neo" from the Matrix. The superuser can walk through walls, stop bullets and so on.

When your system is first getting going, you can't assume anything. There probably aren't any rights in the system to check. A user with the "is_bootstrap_user" flag set is a self-reliant superuser. Nothing is read from the database, no ACLs are checked. You probably never need to do anything with bootstrap users.