Permission system

Commands 2#

Explicit grants (Farmstead build)#

config.json ships with permissions.requireExplicitGrant: true. A player gets a command only after the node is explicitly granted in LuckPerms (or in the internal manager when the external adapter is off). defaultValue: true in PermissionRegistry does not open a node on its own.

OP level 2+ still passes while opsBypassPermissions: true. To make operators follow the same rules as players, set opsBypassPermissions: false.

The old behaviour, "almost every gameplay command is open to everyone until you deny it", comes back only one way: requireExplicitGrant: false.

The "Detailed guide" section below is the original upstream text. It still describes silent grants via defaultValue. For this build, rely on the chain in this page's caveats and on the Quick start.

To check the live result: /permissions debug <player> — the output includes requireExplicitGrant.

/permissions create group vip
/permissions group vip setpriority 10
/permissions group vip setprefix &b[VIP] 
/permissions group vip add neoessentials.teleport.home
/permissions group vip inherit add default
/permissions user Steve setgroup vip
/permissions info group vip

/permissions user Steve addtemp neoessentials.fly 1d
/permissions user Steve listtemp
/permissions check user Steve neoessentials.fly
/permissions user Steve removetemp neoessentials.fly

/permissions debug Steve
/permissions check user Steve neoessentials.moderation.kick
/lp group moderator permission set neoessentials.moderation.kick true
/permissions check user Steve neoessentials.moderation.kick

/permissions check user Steve neoessentials.admin
/permissions check user Steve neoessentials.economy.eco
/permissions check user Steve neoessentials.economy.sellmultiplier.300
/help

/permissions group vip context add world:the_end neoessentials.fly allow
/permissions group vip context list
/permissions group vip context remove world:the_end neoessentials.fly

Configuration#

permissions.json#

Permissions 28#

Detailed guide#

Last updated: 2026-04-01 · Version: 1.0.2.6+build.28 (Mail permission-node section re-verified 2026-08-25 against v1.0.5+build.54 — the rest of this ~1500-line reference has not had a full node-by-node re-audit since the version above; treat other sections as probably-but-not-recently-verified accurate) Source of truth: PermissionRegistry.registerAllPermissions() in the mod source.
All nodes listed here are actively registered and recognised by the permission engine.
Nodes marked ✅ default are granted to every player automatically (including non-OP).
Nodes marked op-only require explicit grant or OP level 2+ unless overridden.

Table of Contents#

1. Configuration
2. How Permissions Work
3. Group Priorities
4. Temporary Permissions
5. Contextual Permissions
6. Permission Conditions
7. Permission Aliases
8. API for Other Mods
9. Wildcards & Inheritance
10. Dynamic Nodes
11. Permission Nodes — Full Reference
    • Core
    • Economy
    • Teleportation
    • Kits
    • Items
    • Chat & Messaging
    • Moderation
    • Miscellaneous Utilities
    • Admin & Config
    • Permission System Commands
    • Web Dashboard
12. Example groups.json
13. External Permission Mods

Configuration#

config.json → permissions section:

opsBypassPermissions vs vanillaOpFallback

Setting	When it fires	Effect
opsBypassPermissions: true	Before any permission check	OPs always get in, permission system not consulted at all
vanillaOpFallback: true	After all checks return false	OP gets in only when every other system denied or failed — a safety net, not a bypass

Most servers should keep both true (the defaults). Set opsBypassPermissions: false + vanillaOpFallback: true if you want OPs to be subject to normal permission management in LuckPerms/FTB Ranks, while still having a lockout-prevention net for when those systems fail.

Permission data file: neoessentials/permissions.json

How Permissions Work#

1. When a player runs a command, PermissionValidator.validatePermission() is called.
2. It checks PermissionAPI.hasPermission(uuid, node).
3. PermissionAPI checks in this order:
4. Emergency mode — if the permission system failed to initialise at startup, all checks immediately answer true for OPs and false for everyone else. Run /neoe reload once the config is fixed to exit this mode.
5. opsBypassPermissions — if enabled and the player is OP (level 2+), true is returned immediately without consulting any permission system.
6. External adapter (LuckPerms / FTB Ranks) — if configured and healthy, its answer is used. If it throws an exception or is marked unhealthy (5+ consecutive failures) execution falls through.
7. Internal permissions.json — the built-in group/user engine is consulted. Checks explicit grants, group membership, wildcard nodes, and inheritance.
8. vanillaOpFallback — if enabled and the player is OP (level 2+), true is returned as a last resort regardless of what steps 3–4 said. This fires only when all other systems returned false or failed.
9. If denied, the player sees: You don't have permission to use this command. §7Required: §f<node> §8(<human-friendly description of the node, if registered>)

Group Priorities#

Every group has an integer priority field (default 0). When a group inherits from multiple parent groups, the parents are checked in descending priority order — the highest-priority group in the inheritance chain is consulted first.

Why it matters: Negative permissions (e.g. -neoessentials.teleport.tpr) and positive grants in a higher-priority parent win over lower-priority parents. Without explicit priorities the check order is unspecified.

Commands:

Example: Group vip (priority 10) and group donor (priority 5) both inherited by vip-donor: - Permissions are checked: vip-donor own → vip (priority 10) → donor (priority 5) → default (priority 0)

Typical priority scale:

Temporary Permissions#

Temporary permissions are time-limited grants that expire automatically — no manual revocation needed. They work for both individual players and groups.

Duration format#

Combine d (days), h (hours), m (minutes), s (seconds) in any order:

Commands — users#

Commands — groups#

How it works#

1. The expiry timestamp (UTC epoch-ms) is stored alongside the permission node.
2. Resolution order — temp permissions are evaluated after negative-permission (-node) denials but before regular user and group permissions. An explicit -node deny still wins.
3. Auto-expiry — a server-tick handler runs every 30 seconds. When an entry's timestamp has passed: - The entry is removed from memory and from disk (playerdata.json / permissions.json). - If the affected player is online they receive the chat message §eYour temporary permission §f<node>§e has expired. - The expiry is written to the audit log with executor SYSTEM and action USER_TEMP_PERM_EXPIRED / GROUP_TEMP_PERM_EXPIRED.
4. Restart safety — temp permissions are persisted on disk. On reload, only entries whose expiry is still in the future are loaded; expired entries are silently discarded.

Worked example#

# Grant a player event-only creative permissions for 2 hours:
/permissions user Steve addtemp neoessentials.fly 2h
/permissions user Steve addtemp neoessentials.gamemode.creative 2h

# Give the vip group a bonus ability for 24 hours:
/permissions group vip addtemp neoessentials.fly 1d

# Check what's active:
/permissions user Steve listtemp
# → neoessentials.fly          — expires in 1h 58m 32s
# → neoessentials.gamemode.creative — expires in 1h 58m 32s

Audit log events#

Contextual Permissions#

Contextual permissions are per-world, per-gamemode, or time-of-day overrides layered on top of the regular permission resolution chain. They let you do things like:

• Give players neoessentials.fly only while they are in a creative-mode world.
• Deny neoessentials.chat.color during night-time on a hardcore-PvP server.
• Grant VIP neoessentials.teleport.tpr only in the Overworld.

Resolution order with context#

When a PermissionContext is supplied the resolution chain becomes:

1. Context deny (user) → return false
2. Context deny (group, inheritance-aware) → return false
3. Regular negative deny (user) → return false
4. Regular negative deny (group) → return false
5. User temp-permission grant → return true (then evaluate condition)
6. Context grant (user) → return true (then evaluate condition)
7. Regular user permission grant → return true (then evaluate condition)
8. Context grant (group, inheritance-aware) → return true (then evaluate condition)
9. Regular group permission grant → return true (then evaluate condition)

Context denies always win over regular grants — they cannot be overridden from below.

Supported context keys#

All keys have tab-completion in /permissions.

Commands — groups#

Commands — users#

Worked example#

# Give the vip group fly only in the creative world:
/permissions group vip context add world:creative_world neoessentials.fly allow

# Deny everyone chat colours during night-time:
/permissions group default context add time:night neoessentials.chat.color deny

# Give a player creative-only permissions, then check them:
/permissions user Steve context add gamemode:creative neoessentials.more allow
/permissions user Steve context list

Storage#

Contextual overrides are saved in: - Groups → neoessentials/permissions.json under "contextualPermissions" - Users → neoessentials/permissions/playerdata.json under "contextualPermissions"

Existing files without the key are treated as having no overrides — fully backward-compatible.

Audit log events#

Permission Conditions#

Conditions are optional runtime expressions attached to a permission node. When the permission would otherwise be granted, the condition is re-evaluated against the player's current context. If the condition fails the grant is withheld (the player does not see a "no permission" message — the permission is simply absent at that moment).

Conditions are a secondary filter on top of the regular grant. They cannot make a denied permission succeed.

Condition syntax#

atom     ::= "time:day" | "time:night"
           | "world:<name>"           e.g. world:overworld
           | "gamemode:<mode>"        e.g. gamemode:survival
           | "health:above:<0-20>"    e.g. health:above:10
           | "health:below:<0-20>"    e.g. health:below:5
           | "op:true" | "op:false"
compound ::= atom (" AND " atom)*    — ALL atoms must match
           | atom (" OR "  atom)*    — ANY atom must match

Examples#

How to set a condition#

Conditions are set programmatically via PermissionsService (see API for Other Mods) or directly via the PermissionUser/PermissionGroup Java API. In-game /permissions condition commands are planned for a future build.

Storage#

Conditions are persisted under "conditions" in the same JSON files as regular permissions.

Permission Aliases#

The alias system maps short or legacy node names to their canonical NeoEssentials equivalents. Aliases are resolved transparently before every permission check — neither the player nor the admin needs to know whether a legacy name was used.

Storage#

Storage note: As of the DataStore migration, aliases are persisted through the active DataStore (see Storage Backend) in a permission_aliases collection — one record per alias, each holding alias and target fields. With the default json backend this lives at neoessentials/store/permission_aliases.json; with sqlite/mysql it's a table in the configured database.

config/neoessentials/permission_aliases.json is now only consulted for a one-time legacy migration: if the permission_aliases collection is empty on startup, any aliases found in that file are imported and the collection becomes the source of truth from then on. Editing the legacy file after that point has no effect.

{
  "essentials.fly"      : "neoessentials.fly",
  "essentials.warp"     : "neoessentials.teleport.warp",
  "essentials.home"     : "neoessentials.teleport.home",
  "efly"                : "neoessentials.fly",
  "mymmod.feature"      : "neoessentials.admin"
}

• Aliases are loaded from the DataStore on start and on /permissions reload.
• Empty collection (and no legacy file to migrate) → no aliases active (silently ignored).
• Changes made via the API or /permissions commands are written straight to the DataStore.
• Aliases are one-directional (alias → canonical). The canonical node itself is never affected.

Registering aliases via API#

NeoEssentialsAPI.getPermissionsService().registerAlias("essentials.fly", "neoessentials.fly");

See API for Other Mods for the full API reference.

API for Other Mods#

Other NeoForge mods can interact with NeoEssentials' permission system using the clean PermissionsService interface — no need to import internal NeoEssentials classes.

Getting the service#

import com.zerog.neoessentials.api.NeoEssentialsAPI;
import com.zerog.neoessentials.api.permissions.PermissionsService;
import com.zerog.neoessentials.permissions.PermissionContext;

PermissionsService perms = NeoEssentialsAPI.getPermissionsService();

Permission checks#

// Simple check (no context)
boolean canFly = perms.hasPermission(player.getUUID(), "neoessentials.fly");

// Convenience overload — builds context automatically
boolean canFly = perms.hasPermission(player, "neoessentials.fly");

// Full context-aware check
PermissionContext ctx = perms.contextFor(player);
boolean granted = perms.hasPermission(player.getUUID(), "mymod.feature", ctx);

Registering your mod's permission nodes#

Registered nodes appear in /permissions search and tab-completion:

// Single node
perms.registerPermission("mymod.feature.use", "Enables the cool feature");

// Bulk
perms.registerPermissions(Map.of(
    "mymod.admin",   "Admin access",
    "mymod.edit",    "Edit items",
    "mymod.view",    "View items"
));

Registering aliases#

perms.registerAlias("mymod-legacy.feature", "mymod.feature.use");

Querying player info#

String group  = perms.getGroup(player.getUUID());   // e.g. "vip"
String prefix = perms.getPrefix(player.getUUID());  // e.g. "§6[VIP] "
String suffix = perms.getSuffix(player.getUUID());  // e.g. " §7✦"
Set<String> nodes = perms.getPlayerPermissions(player.getUUID());
Collection<String> groups = perms.getGroupNames();

System state#

boolean emergency = perms.isEmergencyMode();        // true = OP-fallback-only mode
boolean external  = perms.isUsingExternalAdapter(); // true = LuckPerms/FTB Ranks active

Full method reference#

Wildcards & Inheritance#

Negative permissions — prefix a node with - to explicitly deny it even if a wildcard grants it.
Example: give neoessentials.* then add -neoessentials.item.enchant.unsafe to deny unsafe enchanting.

Note on startup warnings (fixed in v1.0.2.6+build.7): Older builds logged WARN: Invalid permission format: neoessentials.spawner.* (and fireball.*, warps.*) at startup because the internal permission validator did not recognise the .* suffix. The permissions themselves worked at runtime in all versions; only the registration log was wrong. The validator is now fixed and no warnings are logged for valid wildcard nodes.

Dynamic Nodes#

These are not pre-registered but are checked at runtime:

Home limit#

Pattern: neoessentials.home.<number> (1–100)
The highest number the player has is used as their home limit.
Example: neoessentials.home.5 → player can set 5 homes.
If no home-limit node is found, the config default is used.

Warp limit#

Pattern: neoessentials.warp.limit.<number> (1–100)
Example: neoessentials.warp.limit.10 → player can create 10 player-warps.
Special: neoessentials.warp.limit.unlimited → no limit.

Per-kit nodes#

Pattern: neoessentials.kits.<kitname> — grants access to that specific kit.
Pattern: neoessentials.kits.<kitname>.nocooldown — bypasses the cooldown for that kit.
These are registered automatically when a kit is created via /createkit.

Permission Nodes — Full Reference#

Core#

Economy#

Teleportation#

Admin Teleport

Teleport Requests (TPA)

Home System

Warp System

Spawn System

Misc Teleport

Kits#

Player State & Admin Tools#

Items#

Server Admin Commands#

Utility Commands#

Item Customisation & Miscellaneous#

Home & Warp Enhancements#

World Interaction & Fun Commands#

Player Info & Admin Tools#

Chat & Messaging#

Private Messaging

Mail

Moderation Chat

/mute, /unmute, and /mutelist all enforce the same neoessentials.chat.mute node — there is no separate chat.unmute/chat.mutelist node to grant.

Formatting & Colours

Chat Channels

Anti-Spam Bypasses

Moderation#

Both /jail and /jailfor enforce the same neoessentials.moderation.jail node — there is no separate node to gate timed jails apart from indefinite ones.

Miscellaneous Utilities#

Player Info

Nicknames

Server Info

Portable Workstations

Book & Sign

AFK, Gamemode & Other

Admin & Config#

Permission System Commands#

Web Dashboard#

Unlike the sections above, dashboard nodes are not pre-registered via PermissionRegistry.registerAllPermissions() — they are checked ad hoc by the /dashboard and /dashboardregister commands and the dashboard's own auth layer, so they won't appear in /permissions list / /permissions search. Grant them explicitly per group.

Example groups.json#

{
  "defaultGroup": "default",
  "groups": [
    {
      "name": "default",
      "prefix": "§7",
      "suffix": "",
      "priority": 0,
      "permissions": [
        "neoessentials.use",
        "neoessentials.economy.balance",
        "neoessentials.economy.pay",
        "neoessentials.economy.pay.toggle",
        "neoessentials.economy.baltop",
        "neoessentials.teleport.request.tpa",
        "neoessentials.teleport.request.tpahere",
        "neoessentials.teleport.request.accept",
        "neoessentials.teleport.request.deny",
        "neoessentials.teleport.request.cancel",
        "neoessentials.teleport.home",
        "neoessentials.teleport.home.set",
        "neoessentials.teleport.home.delete",
        "neoessentials.teleport.home.list",
        "neoessentials.home.3",
        "neoessentials.teleport.warp",
        "neoessentials.teleport.warp.list",
        "neoessentials.teleport.spawn",
        "neoessentials.teleport.back",
        "neoessentials.teleport.death",
        "neoessentials.teleport.tpr",
        "neoessentials.kits.use",
        "neoessentials.kits.list",
        "neoessentials.item.dispose",
        "neoessentials.chat.msg",
        "neoessentials.chat.reply",
        "neoessentials.chat.ignore",
        "neoessentials.chat.unignore",
        "neoessentials.chat.msgtoggle",
        "neoessentials.chat.channel.local",
        "neoessentials.chat.channel.global",
        "neoessentials.chat.mention",
        "neoessentials.chat.itemlink",
        "neoessentials.mail",
        "neoessentials.mail.send",
        "neoessentials.mail.clear",
        "neoessentials.list",
        "neoessentials.near",
        "neoessentials.seen",
        "neoessentials.whois",
        "neoessentials.ping",
        "neoessentials.realname",
        "neoessentials.motd",
        "neoessentials.rules",
        "neoessentials.helpop",
        "neoessentials.afk",
        "neoessentials.anvil",
        "neoessentials.crafting",
        "neoessentials.grindstone",
        "neoessentials.smithing",
        "neoessentials.stonecutting",
        "neoessentials.book",
        "neoessentials.sign",
        "neoessentials.nick",
        "neoessentials.suicide",
        "neoessentials.depth",
        "neoessentials.compass",
        "neoessentials.getpos",
        "neoessentials.info"
      ],
      "inherits": []
    },
    {
      "name": "vip",
      "prefix": "§6[VIP] §f",
      "suffix": "",
      "priority": 10,
      "permissions": [
        "neoessentials.home.10",
        "neoessentials.teleport.top",
        "neoessentials.teleport.jump",
        "neoessentials.teleport.jumpto",
        "neoessentials.nick.color",
        "neoessentials.chat.color",
        "neoessentials.chat.format",
        "neoessentials.chat.richtext",
        "neoessentials.teleport.warp.create",
        "neoessentials.warp.limit.5",
        "neoessentials.item.repair",
        "neoessentials.sign.colors"
      ],
      "inherits": ["default"]
    },
    {
      "name": "moderator",
      "prefix": "§2[Mod] §f",
      "suffix": "",
      "priority": 50,
      "permissions": [
        "neoessentials.moderation.ban",
        "neoessentials.moderation.banip",
        "neoessentials.moderation.banlist",
        "neoessentials.moderation.tempban",
        "neoessentials.moderation.unban",
        "neoessentials.moderation.unbanip",
        "neoessentials.moderation.kick",
        "neoessentials.moderation.kickall",
        "neoessentials.moderation.freeze",
        "neoessentials.moderation.unfreeze",
        "neoessentials.moderation.freezeall",
        "neoessentials.moderation.unfreezeall",
        "neoessentials.moderation.freezelist",
        "neoessentials.moderation.jail",
        "neoessentials.moderation.unjail",
        "neoessentials.moderation.setjail",
        "neoessentials.moderation.jaillist",
        "neoessentials.moderation.jailinfo",
        "neoessentials.moderation.vanish",
        "neoessentials.moderation.seevanished",
        "neoessentials.moderation.vanishlist",
        "neoessentials.moderation.notify",
        "neoessentials.chat.mute",
        "neoessentials.chat.unmute",
        "neoessentials.chat.mutelist",
        "neoessentials.chat.socialspy",
        "neoessentials.chat.staff",
        "neoessentials.staff",
        "neoessentials.helpop.receive",
        "neoessentials.whois.detailed",
        "neoessentials.nick.others",
        "neoessentials.teleport.admin.tp",
        "neoessentials.teleport.admin.tphere",
        "neoessentials.teleport.admin.tpo",
        "neoessentials.home.20",
        "neoessentials.warp.limit.unlimited",
        "neoessentials.dashboard.moderator"
      ],
      "inherits": ["vip"]
    },
    {
      "name": "admin",
      "prefix": "§c[Admin] §f",
      "suffix": "",
      "priority": 100,
      "permissions": [
        "neoessentials.*"
      ],
      "inherits": ["moderator"]
    }
  ]
}

External Permission Mods#

Overview — Three Permission Tiers#

NeoEssentials supports three configurations:

Compatibility Report (startup log)#

At every startup NeoEssentials logs an External Permissions Compatibility Report:

╔══════════════════════════════════════════════════════════════════════╗
║        NeoEssentials — External Permissions Compatibility Report      ║
╠══════════════════════════════════════════════════════════════════════╣
║  Active adapter  : FTB Ranks                    v2101.1.3           ║
║  Health status   : ✓ HEALTHY                                         ║
╠══════════════════════════════════════════════════════════════════════╣
║  Installed permission mods:                                          ║
║    ftbranks   detected: 2101.1.3   last tested: 2101.1.3   ✓ compatible  ║
╚══════════════════════════════════════════════════════════════════════╝

A ⚠ NEWER THAN TESTED warning is emitted if the installed version is newer than the last-tested minor line. This is informational only — permission checks still proceed.

Built-in Mode — NeoForge Permission Handler Bridge#

As of v1.0.2.6, when no competing permission mod is installed, NeoEssentials automatically registers itself as the active NeoForge permission handler (neoessentials:handler).

This means that any mod that uses NeoForge's PermissionAPI.getPermission(player, node) API — including WorldEdit, FTB Chunks, WTHIT, and others — will have its Boolean permission nodes evaluated against permissions.json.

Adding permissions for external mods

{
  "groups": [
    {
      "name": "admin",
      "permissions": ["neoessentials.*", "worldedit.*", "ftbchunks.*"]
    },
    {
      "name": "builder",
      "permissions": ["neoessentials.player", "worldedit.edit", "worldedit.selection.*"]
    }
  ]
}

Node names must be lowercase. /permissions group add converts input automatically.

Manual handler selection

config/neoforge-server.toml:

# neoessentials:handler = NeoEssentials permissions.json for ALL mods (auto-selected by default)
# neoforge:default_handler = vanilla OP-level only
# luckperms:default = LuckPerms (selected automatically when LuckPerms is installed)
permissionHandler = "neoessentials:handler"

Fallback Chain#

When an external adapter is in use, each permission check follows this fallback chain:

1. emergencyMode?        → YES → OP status only (failsafe)
2. opsBypassPermissions? → YES + player is OP → GRANT (fast-path)
3. External adapter      → healthy? → use its answer (grant or deny)
                         → unhealthy / exception → fall through to step 4
4. Internal permissions.json (fallback when external fails)
5. vanillaOpFallback?    → YES + player is OP → GRANT (last resort)
                         → NO or not OP → DENY

Adapter health tracking: After 5 consecutive runtime exceptions the adapter marks itself UNHEALTHY, internal permissions.json takes over, and a single boxed WARN is logged. The adapter is re-checked on the next /permissions reload.

LuckPerms#

All NeoEssentials permission nodes work normally inside LuckPerms. The built-in permissions.json is not used for checks, but keeps accumulating edits if you switch back.

Context support: When LuckPerms is active, world and server contexts are evaluated using the player's live QueryOptions (updated since build.4).

FTB Ranks#

API probe order: NeoEssentials tries four FTB Ranks API signatures at startup to handle version differences (current, legacy static, alternative naming, older instance method).

Wildcard support for external mods#

The .* wildcard works for any mod prefix:

Compatibility table#

Fine-Grained Command Control#

NeoEssentials uses per-subcommand permission nodes throughout. Every branch of every command tree has its own node, so you can grant or deny individual subcommands without granting the whole command.

How it works#

Every Brigadier branch checks PermissionValidator.validatePermission(source, node) (or validateAnyPermission) before executing. The node is shown in the denied-access message so admins know exactly what to grant.

Examples by system#

Home system

Warp system

Kit system

Economy

Moderation

Permission system commands

Negative permissions as fine-grained deny#

Use a - prefix on any node to explicitly deny a subcommand even when a wildcard grants the parent:

neoessentials.*                       # grant all
-neoessentials.item.enchant.unsafe    # but deny unsafe enchanting specifically
-neoessentials.moderation.banip       # and deny IP banning

GUI Management — Web Dashboard API#

The web dashboard exposes a full REST API for permission management. All endpoints require Bearer token authentication (Authorization: Bearer <token>).

Base URL: http://<server>:<port>/api/permissions

Quick reference#

Example: add a contextual permission via the API#

curl -X POST http://localhost:8080/api/permissions/group/vip/context \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"contextKey":"world:overworld","node":"neoessentials.fly","allow":true}'

Example: register an alias#

curl -X POST http://localhost:8080/api/permissions/aliases \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"alias":"essentials.fly","canonical":"neoessentials.fly"}'