Investigate: Slipstream LSL bridge (FS-style in-world helper), optional / attach-on-demand

sky_line commented

2026-10-05 11:28:21 +00:00

Owner

Investigation / design ticket. Decide whether and how Slipstream gets its own in-world LSL bridge: a small scripted helper that lets the viewer do things only an in-world script can. It could be based on Firestorm's (fslslbridge.*), possibly ported wholesale, but needs thought first. Related: #425 (Area Search Script Info needs it), #426.

What Firestorm's bridge is

On login, FS creates a scripted object in the user's inventory (#Firestorm folder) and wears it on an attachment point.
The viewer and the script talk over a private channel (chat channel / script URL) secured with a per-user secret.
It's used for things only scripts can do:
- Script info: llGetObjectDetails (script counts / memory / time for any object);
- Movelock (hold position against pushes);
- AO sit/stand handling;
- OpenCollar / LockMeister integration;
- other script-only queries (radar / teleport helpers).
Many SL users already have an old #Firestorm LSL Bridge object in their inventory.

Concerns

Attachment slot: a permanently worn object takes a slot, and counts toward the avatar's script load in every region.
Security:
- only the owning viewer may command it (secret + channel validation);
- it must not be spoofable or abusable by other objects;
- it must not leak data;
- it must cope with no-script regions.
Transparency: users should know it exists and what it does; it should be opt-in or clearly disclosed.
Robustness:
- (re)creation when it's deleted or outdated;
- version upgrades of the script;
- attach failures;
- multiple viewers / alts;
- not fighting RLV restrictions (attach/detach locks).

Design options to evaluate

Port FS's bridge wholesale (as-is protocol and features), then adapt naming and settings. Fastest route to feature parity. Check the licence (FS is LGPL, like us), and check what in FS depends on it.
On-demand bridge: attach only when needed (Script Info clicked, movelock enabled, an integration active), and detach when idle. Saves the slot and script load most of the time. Trade-off: attach latency (a second or two), and features that must always run (AO, OpenCollar listening) would keep it attached while they're enabled.
Optional, always-on bridge: a Preferences switch ("Enable Slipstream helper"), default off, with a clear explanation. Features that need it say so and offer to enable it.
Hybrid of 2 + 3: off by default; individual features enable on-demand use; a power user can choose "keep attached".
Reuse an existing FS bridge object in inventory? Probably not (version / security mismatch); create our own #Slipstream Helper.

Features it would enable (prioritise)

Area Search Script Info (#425): on-demand fits well.
Movelock.
AO integration (check what Slipstream's AO situation is).
OpenCollar / LockMeister / RLV-adjacent integrations.
Anything else in FS that depends on the bridge: audit fslslbridge callers in FS.

Deliverable of this ticket

A short design write-up (in the ticket or research/):

what FS's bridge does (protocol, security model, features), and how much code it is;
the chosen approach (wholesale port vs own; on-demand vs optional always-on);
the security review;
then implementation tickets.

**Investigation / design ticket.** Decide whether and how Slipstream gets its own **in-world LSL bridge**: a small scripted helper that lets the viewer do things only an in-world script can. It could be based on Firestorm's (`fslslbridge.*`), possibly ported wholesale, but needs thought first. Related: #425 (Area Search Script Info needs it), #426. ## What Firestorm's bridge is - On login, FS creates a scripted object in the user's inventory (`#Firestorm` folder) and **wears it on an attachment point**. - The viewer and the script talk over a private channel (chat channel / script URL) secured with a per-user secret. - It's used for things only scripts can do: - **Script info:** `llGetObjectDetails` (script counts / memory / time for any object); - **Movelock** (hold position against pushes); - **AO** sit/stand handling; - **OpenCollar / LockMeister** integration; - other script-only queries (radar / teleport helpers). - Many SL users already have an old `#Firestorm LSL Bridge` object in their inventory. ## Concerns - **Attachment slot:** a permanently worn object takes a slot, and counts toward the avatar's script load in every region. - **Security:** - only the owning viewer may command it (secret + channel validation); - it must not be spoofable or abusable by other objects; - it must not leak data; - it must cope with no-script regions. - **Transparency:** users should know it exists and what it does; it should be opt-in or clearly disclosed. - **Robustness:** - (re)creation when it's deleted or outdated; - version upgrades of the script; - attach failures; - multiple viewers / alts; - not fighting RLV restrictions (attach/detach locks). ## Design options to evaluate 1. **Port FS's bridge wholesale** (as-is protocol and features), then adapt naming and settings. Fastest route to feature parity. Check the licence (FS is LGPL, like us), and check what in FS depends on it. 2. **On-demand bridge:** **attach only when needed** (Script Info clicked, movelock enabled, an integration active), and detach when idle. Saves the slot and script load most of the time. Trade-off: attach latency (a second or two), and features that must always run (AO, OpenCollar listening) would keep it attached while they're enabled. 3. **Optional, always-on bridge:** a Preferences switch ("Enable Slipstream helper"), default off, with a clear explanation. Features that need it say so and offer to enable it. 4. **Hybrid of 2 + 3:** off by default; individual features enable on-demand use; a power user can choose "keep attached". 5. Reuse an existing FS bridge object in inventory? Probably not (version / security mismatch); create our own `#Slipstream Helper`. ## Features it would enable (prioritise) - Area Search Script Info (#425): on-demand fits well. - Movelock. - AO integration (check what Slipstream's AO situation is). - OpenCollar / LockMeister / RLV-adjacent integrations. - Anything else in FS that depends on the bridge: audit `fslslbridge` callers in FS. ## Deliverable of this ticket A short design write-up (in the ticket or `research/`): - what FS's bridge does (protocol, security model, features), and how much code it is; - the chosen approach (wholesale port vs own; on-demand vs optional always-on); - the security review; - then implementation tickets.

sky_line added the

feature

label

2026-10-05 11:28:21 +00:00

sky_line referenced this issue

2026-10-05 11:39:43 +00:00

SLua: pull in LL viewer updates since our fork and verify end-to-end readiness for the SLua release #430

sky_line added this to the Slipstream project

2026-10-06 15:04:13 +00:00

sky_line referenced this issue

2026-10-06 16:30:19 +00:00

Client-side AO (animation overrider): own implementation, collar/script compatible, notecard import #496

sky_line referenced this issue

2026-10-06 18:00:50 +00:00

Pose Studio: our own poser (OP Pose HUD UI) with poses shared via the LSL bridge, and consent-based posing of others #500

sky_line referenced this issue

2026-10-07 04:39:41 +00:00

Pose Studio: our own poser (OP Pose HUD UI) with poses shared via the LSL bridge, and consent-based posing of others #500

sky_line commented

2026-10-07 04:39:42 +00:00

Author

Owner

Pose sharing and consent-based posing (#500) will run through the bridge: that makes the bridge a must-have, attached on demand while posing or viewing synced poses.

sky_line referenced this issue

2026-10-07 05:18:47 +00:00

Pose Studio: our own poser (OP Pose HUD UI) with poses shared via the LSL bridge, and consent-based posing of others #500

sky_line referenced this issue from a commit

2026-10-07 23:17:17 +00:00

Pose Studio (#500) phase 2: share poses via the #Slipstream Helper bridge

sky_line commented

2026-10-09 04:40:41 +00:00

Author

Owner

Superseded: the Slipstream Helper bridge (in-world helper used by Pose Studio pose sync) is our in-world bridge now; new bridge features get their own tickets.

sky_line closed this issue

2026-10-09 04:40:41 +00:00

Rows
Columns

Investigate: Slipstream LSL bridge (FS-style in-world helper), optional / attach-on-demand #428

What Firestorm's bridge is

Concerns

Design options to evaluate

Features it would enable (prioritise)

Deliverable of this ticket