Yokefellow - First-Party Apps
Lounge
The first-party community and presence surface where access, decor, status, roles, and social space use Yokefellow rights.
Revised product paper aligned to the stronger Yokefellow document set.
1. What This Paper Is
This paper explains Lounge as a first-party Yokefellow app. Its job is to show what the app is, what role it plays in the platform, how it uses Yokefellow’s existing primitives, and why it belongs inside the system instead of being treated like a disconnected chat, avatar, or room-decorator product. It is not the Whitepaper, not the Mechanics paper, and not the Developer Docs Hub. It is the product paper for one specific first-party surface built on the Yokefellow system.
The paper should stay product-facing but structurally honest. It should explain Lounge clearly without drifting into vague metaverse language or generic social-app talk. Lounge matters because it gives Yokefellow a native community and presence layer, but that layer only makes sense when it stays tied to Yokefellow’s real rights model, real bucket context, real metadata environment, and real app-layer control boundaries.
2. What Lounge Is
Lounge is Yokefellow’s community and presence surface. It gives users a place to gather, talk, customize an avatar, decorate a persistent personal or shared space, and use NFT-backed items, access, status, and permissions inside a social environment built on Yokefellow’s existing rails.
It is the community app for the platform, but it is more than chat. It is where identity, ownership, access, decor, and social presence become lived parts of the Yokefellow system instead of staying abstract.
3. What Lounge Is Not
Lounge is not a generic chat app, not a free-floating avatar world, and not a place where every cosmetic item automatically carries Yokefellow meaning just because it appears on a screen. It is also not a separate identity system beside Yokefellow’s bucket, rights, and NFT structure.
It should not invent new meaning for assets that were never configured to matter there. It should not imply that every room, badge, role, or object is equally durable, transferable, or platform-wide. And it should not pretend that social presence removes the limits already attached to the rights, metadata, or bucket context underneath it.
4. The Core Model
The core model is simple.
A user has a Yokefellow presence. That presence can include an avatar, visible status, visible affiliations, owned or equipped items, and access to one or more spaces. Some of what the user can wear, place, show, enter, host, or control comes from bucket-linked rights, recognized NFTs, and the metadata attached to them. Some spaces may be personal. Some may be public. Some may be gated by status, role, or bucket-linked participation. The app is where those things become usable in a persistent social setting.
That means Lounge is not only a cosmetic layer. It is a social surface built on rights, NFTs, metadata, and bucket-linked meaning.
5. Why Lounge Belongs on Yokefellow
A normal community or avatar app can let people gather, talk, and decorate, but it usually does not preserve the deeper meaning of the things users hold. Yokefellow can do better because the items, permissions, statuses, and access surfaces can already come from structured bucket participation, NFT issuance, and bucket-linked rights. The Whitepaper already argues that Yokefellow matters because it can keep terms, participation, redemption, proof, and records attached to one system rather than scattering them. Lounge extends that same logic into community and presence.
Lounge also fits Yokefellow because the Rights paper already gives the exact kinds of value the app needs: access rights, participation rights, status rights, decor and display rights, control rights, and team- or owner-linked rights. Lounge is where those rights stop being only described and start being used in a visible social space.
6. Recognized Yokefellow Identity, Rights, and Items
Lounge should be understood as a surface for recognized Yokefellow-native identity, rights, and items, not as a loose container for arbitrary external objects that the platform cannot actually interpret. The platform already has real recognition boundaries around buckets, collections, outputs, and permissions. That matters here.
The app should therefore care most about avatars, items, badges, room permissions, and social controls that the platform can actually recognize through its own bucket, rights, collection, and metadata environment. That gives users a clearer standard of what is real inside Lounge and keeps the app aligned with Yokefellow’s actual stack instead of turning it into a vague profile layer with optional token wallpaper.
7. Personal Space
Lounge should give users a persistent place they can shape as their own.
That may be a room, lounge, suite, corner, plot, display surface, or some other user-held environment. The important point is that it feels like a real Yokefellow space rather than only a profile page. Users should be able to decorate it, present themselves inside it, and treat it as a continuing surface rather than a one-session gimmick.
This is where decor and display rights matter most. The Rights paper already defines decor and display rights as the right to place, show, use, or present something in a defined surface or context. Lounge is where those rights should become native and obvious.
8. Shared Social Space
Lounge is also where people gather, not just where they decorate.
That means it should support public gathering spaces, private spaces, gated spaces, team or community rooms, event-linked rooms, social and conversation surfaces, and hosted social moments. It should support both “this is my space” and “this is where we gather.”
This matters because Lounge is the community app, not only a personal-room app. The shared-space layer is what lets bucket-linked groups, teams, events, and other Yokefellow communities become socially visible instead of remaining only pages or records elsewhere in the platform.
9. Access, Status, and Role Logic
Lounge should not treat all rights as cosmetic. Some rights and NFTs should control what the user can actually do.
That means bucket-linked rights, recognized NFTs, or other platform-recognized role signals may determine what spaces a user can enter, what spaces a user can host, what items a user can place, what circles or rooms a user belongs to, what visible roles or standings they carry, and what moderation or stewardship powers they hold.
This fits cleanly with Yokefellow’s existing access, participation, status, and control-right logic. Lounge should therefore be read as a use surface for those rights, not as a separate social hierarchy invented without bucket or rights context.
10. NFTs and Metadata in Lounge
This is one of the most important parts of the paper.
Lounge should not treat NFTs as only static collectibles. It should treat them as usable carriers of Lounge utility. NFT metadata should help determine what the user can use in the app. That may include decor items, avatar items, access rights, room rights, display rights, status surfaces, interactive objects, and other usable social-layer assets.
The Rights paper already says the NFT is often the container that carries the right, but the right is the thing that matters to the user. Lounge should preserve that logic. The NFT is the carrier. The metadata helps define how it works in the Lounge environment. The user-facing meaning is the access, display, status, decor, or utility it grants.
11. The Issuing Bucket Still Defines Meaning
This is the most important rule in the paper.
Lounge does not overwrite the meaning of what the user holds. The issuing bucket still defines what an item, badge, access object, role-linked NFT, or decor-right carrier actually means. The offering path and rights structure still define what the holder is receiving. The bucket context still matters.
That also means Lounge should not magically broaden a narrow right into a platform-wide one. A bucket-linked role does not become universal authority just because it is visible in Lounge. An event-linked access object does not become permanent room access if its real scope was temporary. A display object does not become a control right unless the issuing structure actually granted that power.
12. Lifecycle State Matters in Lounge
Lounge should not display only item identity. It should care about state. If a recognized NFT or right carries lifecycle state, use state, depletion state, upgrade state, event state, or other material metadata, that information should affect how the object behaves and how the user reads it inside the Lounge environment.
A room item may be placeable but not transferable. A badge may reflect a current standing rather than a permanent one. An access object may open one room or season but not another. A transformed or upgraded item may appear differently after use. A redeemed or depleted asset should not be shown as if it were still fully fresh.
That means metadata is not only decoration. If metadata carries material information about what the object currently is, that information is part of what the user is actually using in Lounge.
13. Moderation, Hosting, and Stewardship
Since Lounge is the community app, it needs more than entry and item placement. It also needs community control surfaces.
That means the app should support host rights, room-management rights, moderation roles, posting or speaking permissions, event-hosting rights, and stewardship roles for shared spaces. These should not be treated as generic admin switches floating above the system. Where possible, they should be bucket-linked, role-linked, or NFT-linked so the rights to host, manage, moderate, or steward still make sense in Yokefellow terms.
At the same time, the paper should stay honest about control posture. Not every moderation action is an onchain fact. Some of this is application-layer social control, policy, and operator-managed behavior. That does not make it unreal. It means Lounge should describe these powers clearly instead of pretending every social action is enforced in the same way as a contract-backed transfer or mint.
14. Persistence Without Pretending Everything Is Onchain
Lounge should feel persistent.
That means the user’s avatar, room state, placed items, affiliations, unlocked objects, and visible roles should feel like ongoing parts of the system rather than temporary session effects. A user should be able to return and still find their space, their visible state, and their unlocked utility meaningfully intact.
But persistence should be described honestly. Some underlying facts may be onchain, such as recognized ownership or collection state. Some visible Lounge state will still be offchain application state, synchronization, moderation state, or metadata-driven interpretation layered above those harder facts. The app should feel durable without pretending every visible social detail is independently contract-enforced.
15. How Lounge Uses Yokefellow’s Rails
Lounge should be explained through Yokefellow’s existing rails rather than as an isolated social product. The meaning side comes from buckets, offerings, rights, and metadata. The ownership side comes from recognized collections and recognized holdings. The permission side comes from bindings, role logic, and bucket-linked control. The visibility side comes from app-layer presentation built on top of those facts.
That matters because Lounge is not inventing a second Yokefellow. It is using the same platform structure in a different surface. When Lounge works properly, it proves that Yokefellow can support a social and presence layer without severing identity, access, decor, and status from the bucket and rights environment that gave them meaning in the first place.
16. What the User Should Be Able to Read in Lounge
A good Lounge surface should show more than chat and avatar cosmetics. It should show the user’s current space, avatar, visible items, visible status, accessible rooms, and bucket-linked or NFT-linked utilities in a way that makes clear what is decorative, what is social, and what is functional.
A user should be able to answer these questions inside Lounge:
What spaces can I enter.
What space is mine.
What can I place here.
What does this NFT or right unlock here.
What role or status do I visibly hold here.
What groups, teams, or communities am I tied to here.
That is the correct Yokefellow version of a community app.
17. Why Lounge Matters
Lounge matters because it proves Yokefellow is not only a funding, rights, or issuance system. It can also support a persistent community and presence layer built on those same rails.
That makes the platform stronger in several ways. It gives users a place where ownership and rights become lived social reality. It gives NFTs visible use beyond simple holding. It gives communities a space to gather that is still rooted in Yokefellow participation. It gives identity, decor, status, access, and bucket-linked meaning a persistent home inside the platform.
That is a big part of how Yokefellow stops being only a tool people use for one transaction and becomes a place people continue to inhabit.
18. Why Building Buckets Early Matters
Lounge gets stronger when bucket structure is correct early. If buckets are built cleanly, then the NFTs and rights issued from those buckets carry cleaner meaning, cleaner access rules, cleaner status logic, cleaner decor utility, cleaner moderation logic, and cleaner metadata for use in the Lounge environment.
Since the bucket is where the initiative, terms, redemption, proof, and responsibility are made explicit, stronger buckets produce stronger Lounge utility later. Better bucket structure directly improves what Lounge can show and what users can trust once those social surfaces open around the bucket-linked world.
19. Closing Frame
Lounge should be understood as Yokefellow’s community and presence surface. It gives users a place to gather, talk, customize avatars, decorate persistent personal or shared spaces, and use recognized bucket-linked or NFT-backed items, access, status, and permissions inside a social environment built on Yokefellow’s existing rails.
It is not just chat, not just a room decorator, and not just a profile surface. It is the community layer where Yokefellow identity, ownership, metadata-driven utility, and bucket-linked meaning become visible and usable in everyday platform life. It does not invent new rights out of thin air. It does not flatten every item into the same kind of cosmetic object. It provides the native social surface where Yokefellow presence can actually be inhabited.