The client's Settings > T5DE chooses the hub from the next start on (POST /hub/server, kept in server.json);
without a choice, -channel (which the client passes) decides: staging for nightly and dev, T5DE's hub for
releases. $T5DE_HUB still wins. Each hub's sign-in, product IDs and products are kept in their own folder
(T5DE's hub in the data folder as before, others in hubs/<host>), so a hub never gets another's token and
product IDs from two hubs never clash; a sign-in saved for another hub is ignored. Signing in always goes to
this run's hub.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Chat Rooms > Manage (the t5de-room-manage patch) lists the person's T5DE rooms
(room_management_info.php?t5de=1) and saves them from IMVU's room dialog (room_management.php: create
with t5de=1, edit and delete naming a hosted room) as hub calls: the room, its moderators by name, and a
picture from the person's IMVU gallery, uploaded to the hub. The hub's refusals show in the dialog
(hub.Error keeps their message).
Avatar cards get show_ap_plus again, which IMVU stopped sending, from the person's public IMVU profile
(is_ap_plus).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Hosted rooms' instance IDs start with their owner's IMVU account now, so the client asks about their
products as the owner itself, and the mapping from 2100000000 is never used.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The invitation carries the room as the dialog shows it (name, owner, image, occupancy, description)
and the inviter's picture, age and gender from IMVU's public profile. Accepting names the room
(room_instance_id), so the client joins it as a public room with the invite rather than opening a
private chat, and getParticipants before joining asks the hub, so the client sees its inviter there.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The client's own room actions work in hosted rooms, through the hub (t5de-hub's docs/hosted-rooms.md,
Phase 2): a "*boot" line goes to the room, then to the hub as room.boot; refused joins are declined as
the client's own are (booted ones as booted). Invitations: chat.attemptInvite polls the hub's answer,
and the invitee's client gets chatInvite on its user queue, accepting with the invite. Favorites
(favorite_rooms.php, add/removeFavoriteRoom, the favorites list), ratings (room_rating.php), the room
card's moderators, image and score, and room_occupancy queues fed from room.watch.
Web API parameters are read from JSON bodies too (imvu.http.securePost), and hosted rows added to an
empty IMVU list keep their flags numeric ("0" counted as set).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
room_info.php (the room card's participants, asked for every room) is answered for hosted rooms from
the hub (it was refused as naming a hosted room, which the client showed as an error), with max_users;
it and getRoomCardInfo get t5de_t5 for hosted and decorated rooms, as do the person's own rooms in
room_management_info.php.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Hosted rooms, and IMVU rooms the hub has decorations for (asked 20 at a time), on every page; hosted
rooms are added to recent rooms from the hub's recent list when it has one.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The client doesn't ping while it's sending, so when the proxy answers its frames itself (everything it
sends in a hosted room), IMVU's gateway saw an idle connection and closed it after about a minute. A
ping now goes to the gateway in place of each answered frame. And after a reconnect, hosted rooms'
queues are taken out of C2gOpenFloodgates and answered here (the gateway never answered them, so the
client gave up and closed the room).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- The seat chosen on joining, and "*msg SeatAssignment" room seats, go to the hub, so people joining get
free seats (both stood on seat 1).
- Instance IDs are "<owner>-<2100000000+n>" (the hub's change): the client takes the owner from them, so
owners can decorate their rooms.
- A hosted room's scene carries community products as the hub's IDs (placements too), turned into local
IDs by each proxy, instead of being stripped; saved and loaded scenes translate placements too.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
After the owner saves, IMVU's server sends everyone the saved room ({"command": "SetRoomState"} from
admin on the chat's control mount), which has no decorations: the proxy now adds them to it, and takes
community products out of any outgoing one. A change notice from the hub also no longer empties the
remembered decorations while the new ones are asked for (a broadcast arriving meanwhile went through
without them).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Community products are taken out of rooms their owners save and broadcast, kept on the hub per room,
and added back when anyone with T5DE loads the room or gets its owner's broadcast; the hub's decor
notice resends the room with the new ones. Placements are stored with the hub's product ID.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Hosted rooms (internal/hosted): room calls for them answered here, their IMQ queues served (a new
proxy.IMQRouter hook takes them out of subscriptions to IMVU), chat relayed through the hub's
WebSocket (hub.Client gains Send, OnRoom and OnConnect), the room list extended, room products
checked against the real owner, and anything else naming a hosted room kept from IMVU.
T5DE_INSTANCE gives a second client's proxy its own data folder and log.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
POST http://t5de-proxy.local/badges {imvuIds} -> {badges}: which IMVU accounts show the T5 badge,
asked of the hub (POST /api/v1/badges, in batches of 200) and remembered for 10 minutes.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
- The inventory's Recently Added puts T5 products added to the library in the last 30 days first.
- The shop's T5 listing follows its sort menu: Best Match ranks by name, Newest by upload date
(oldest first ascending); ratings and prices (T5 products have neither) sort by newest.
- Outfit cards: outfit_products.php gets the outfit's community products added (not for sale),
find_bundle.php is asked about IMVU's products only, and removing one in the card (remove_pids)
keeps it from IMVU and forgets it in the outfit.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Trying a product on in the shop asks api.imvu.com/product/product-<id>/uml_products for related
products; the guard refused it for T5 products, and the client showed an error. Community products
now get an empty list (and not found for anything else) from the proxy.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The shop's T5 filter (maturity_rating "t5") is answered from the hub's products, fetched so they can be
shown and tried on; buying T5 products adds them to the hub library, and product.php details for
community products are answered here.
The client sends some product IDs as floats ("2000000008.0"): product.php passed the worn community
product to IMVU that way. Every ID is now read either way, and products.Guard refuses any request to
IMVU that still names a local ID given out. T5DE_PROXY_DUMP logs request and response bodies.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Saving an outfit (POST /api/outfits.php) sent its community products to IMVU. They're now taken out (any ID in
the community range, known or not), the request re-signed, and the products remembered under the outfit's ID,
then added back when the client loads its saved outfits (marked AP if one is adult).
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A manager runs the hub connection, so signing in or out takes effect while the client runs; the client's T5DE
settings page asks it for the status and to sign in (showing the code and opening the hub's page) or out.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The client never subscribes to its user queue; the proxy now follows every IMQ connection and the signed-in
account (from the login answer), and delivers the refresh event on /user/<id>. Checked live: removing a product
from the library on the hub reloads the client's inventory.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The inventory's product list (test.showInventory) gets the community products the person has: local packs, and
hub products in their library. Hiding one is answered by the proxy (and removes a hub product from the library).
When the library changes, the client is told to load its inventory again, with the server event IMVU sends
after a purchase. A product whose revision or info changes gets a new local ID, since the client keeps product
info for good; names lose characters the client's pages could take as HTML.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The proxy keeps the person's library in a cache folder (hub-products in its data folder), one pack per
product, served like any other pack: the hub says which revision to load and which catalogs host it, each file
comes from a catalog and is checked against the hub's sha256 (files are kept by hash, so a new revision only
downloads what changed), and adult files are fetched with the hub's access token. Products someone wears in a
room that aren't here yet are fetched too, and put on them when they arrive.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The proxy follows the client's IMQ chat subscriptions and tells the hub which chats it's in (and the room, from
chat.getOrMakeChat). For the other T5DE users the hub says are in a chat, it gives the client the community
products it has packs for, as *use and *remove lines from them, and adds them to the whole outfits they send.
It also takes community products out of the outfit the client posts to IMVU's chat participant endpoint, which
had been sending them to IMVU.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The proxy serves products from local packs (t5de-api's format) under local IDs from 2,000,000,000: product
info and permission answers (with the parent's derivation chain from IMVU), the product's CFL, and the shop's
bundle lookup. Community products are taken out of outfit saves and outfit chat commands before IMVU sees
them, remembered per account with the outfit they belong to, and added back when the client loads that
outfit. Changed requests are re-signed with the session key from the login response.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Parses and writes calls and responses with Python 2.7 xmlrpclib's and
IMVU's PHP server's types, keeping struct member order.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The client sends it every HTTP request and its IMQ connection; it makes them with current TLS and
certificates, upgrades IMVU's plain-HTTP hosts to HTTPS, and refuses IMVU's reporting endpoints. CI
tests it and publishes t5de-proxy.exe as nightlies and tagged releases.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
dhkatzandClaude Opus 5.5