Category: SL User Group Meetings

2026 week #32: SL Open Source UG Summary

Posted on by Inara Pey
Hippotropolis Theatre: home of the OSD/TPVD meeting
The following notes were taken from:

  • My chat log of the Open-Source User Group (OSUG) meeting held on Friday, August 7, 2026, together with my chat log of that meeting.
  • No video this week as Pantera is on vacation.
Table of Contents

Meeting Purpose

  • The Open Source User Group (OSUG) meeting is an open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
  • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

Viewer Notes

  • 26.3 is to see a further RC / beta update prior to getting promoted. There has been an increase in log-out failures with the current RC, so LL is working on fixing that.
  • Viewer 26.4 is now confirmed as being the Lua editor viewer (with Linux support), and a further update to that viewer (currently alpha / project status) should be forthcoming in the next week or so.
  • Discussions are still continuing on where to place the viewer-side code for game_control. Per my SUG meeting summary notes, this in part rests on his API work semantic to help with naming controls, etc.
  • Geenz has resumed work on the Graphics Care package (GCP) viewer. 

Other Items

  • Transparent Media on a Prim (MOAP) – the ability to have parts of a MoaP surface be transparent rather than the whole thing –  appears to be moving forward as well. As a general heads up on this, Geenz noted it might bring a few security minded modifications along with it, but no details on this at present.
  • Roxie Linden noted that LL is still actively looking into transcription functionality, and the hope is to evaluate more technologies to make sure a good option for SL is identified.
    • Also being evaluated is transcription accuracy, to allow a fast follow-on for functional translation. Roxie reaffirmed that transcription / translation are being looked at is internal services, rather than utilising any 3rd party solutions, so as to maintain privacy.
    • However, Jerome noted that whether an internal service is created or there is a move to use an external service could come down to issues such as cost, maintenance, etc., – however, privacy will remain a priority either way.
  • A suggestion was put forward for a “decode once, use many” approach to the texture cache (e.g. decode the textures from the asset CDN once, then store them as something like KTX,  which can be streamed directly into the GPU).
    • Brad Linden noted this is actually done for SL Mobile, and that it would be good to standardise on an approach across both Mobile and all viewers.
    • Geenz noted that whilst this would be good, it could be impactful on client performance, noting:
It’s definitely an interesting direction, and one I don’t think would be bad – but I think the bigger question is gonna be how do we do this without decimating every single texture that has text on it?
  • As a part of the above discussion, Geenz noted that moving away from OpenJPG as the graphics API will likely that the initial direction will be Vulkan and Metal (Mac) to start, with the potential for DirectX 12 to be added-in as well (although if LL stick to using slang-rhi, DX12 should be supported anyway).
    • A caveat here was that if LL doesn’t have to directly support hardware outside of what Metal and Vulkan will run on, then they’ll constrain the work to just what is needed.
  • Geenz also hinted that things might be changing more broadly with the graphics pipeline, suggesting that in the future, deferred rendering may not by a part of it – and people should think more in terms of forward+ or clustered. Again, this is not to say this direction will be taken; the comments were more things Geenz is mulling, as was the case with musings on the potential for froxels potentially being something worth looking into.
  • The last part of the meeting was more specific to viewer pull requests (PRs), and bug reports, including:

Next Meeting

2026 week #32: SUG meeting summary

Posted on by Inara Pey
The Simulator User Group meeting place at Longfellow

The following notes were taken from the Tuesday, August 4, 2026 Simulator User Group (SUG) meeting. These notes form a summary of the items discussed, and are not intended to be a full transcript. No video for this meeting – Pantera is on vacation.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
  • The “Leviathan Office Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
  • Meetings are held in text in-world, at this location.

Simulator Deployments

  • The hot fix for some regions failing to grant capabilities correctly to the viewer (and thus crashing the viewer) deployed in mid-July … has a bug (causing log-in and teleport issues).
    • As a result, the fix was rolled back on August 4 for the SLS Main channel and will be rolled back on August 5 for the RC channels.
    • Once the roll-back is complete, things should behave as per the Kumquat simulator update.
    • This roll-back should help alleviate many of the recent region crossing issues people have been experiencing in the last week – see below for more.

Game_Control

  • Leviathan Linden continues to work on game_control (viewer and server-side).
  • Viewer:
    • He has added a “mouse” mode: it is possible to press a button on a game controller and move the viewer’s mouse  the mouse around. This also allows mapping of  mouse left- and right-click function to a controller.
    • However, he noted he is unsure of what to do with the “semantic data” there (e.g. axis values will currently show the delta_X and delta_Y input that is driving the mouse, which isn’t particularly useful; he imagines scripters would be more interested in “mouse_X, mouse_Y”, so he is still wondering about how best to make that info available, if it is needed).
    • He has, however further modified PromptFont (used for the game_control preferences UI) to make it more readable.
  • Server side:
    • As noted during his previous Office Hours meeting, there are some further server-side aspects to game_control he wishes to complete.
    • However, it might be a few weeks before this is in any way ready – and this work needs to be deployed ahead of the viewer-side code becoming generally available in viewers, and will include the required UDP message updates to pack “semantic data” & make it available to LSL via a new function call.

Region Crossings

  • As per the last SUG meeting and the previous Leviathan Office Hours, Pepper Linden has put together some fixes to address vehicular region crossings (see this bug report).
    • This are currently available on the Blake Sea region on Aditi (the Beta grid) for those wishing to test them.
    • Pepper encourages those who can to log-in to Aditi hand test things & provide feedback. Pepper can be reached in-world via IM or via the SL Discord server.
  • In terms of the recent (last week-ish) region crossing issues:
    • These are believed to be related to the bug introduced into the simulator coder, per the simulator notes at the top of this summary.
    • As most of the Blake Sea regions are on the BlueSteel RC channel, it was suggested that once the roll-back on the RC channels scheduled for Wednesday, August 5 has been completed, crossings can be tested there.
    • If people continue to experience issues which appear to be the same as or similar to those experienced prior to the roll-back
    • However, if people continue to experience significant crossing issues, they can message Rider with details on the SL Discord server.
  • A general discussion on region crossings – reporting issues, keeping people informed of changes / updates, etc., formed a major part of the meeting.

Lua Notes

  • Harold Linden has mostly finished the upgrade of the SLua repository to match the current upstream version of Luau.
  • The development version now has integers in Lua, and  support for them has been added to lljson “and friends” so they should be supported when Lua is deployed.
    • He noted this has been a significant change, removing a lot of integer and yield-related code that now has an upstream equivalent, so in the next few weeks people working with Lua  will need to recompile any existing scripts using Lua – although in the future, this will not be necessary, as there will be a compatibility framework which can be used.
  • Rider Linden has rolled out new wrappers for the functions relating to particles and HTTP requests enabling properly-typed tables to be passed to them without having to remember the arcane rule names and values for particle systems. He noted would welcome  PRs that wrap some of the other lists as well.
  • As per my notes from the previous Content Creation User Group meeting, Rider Linden has produced a new version of the VSCode plugin with might tighter integration with the viewer.
    • However, it has been pointed out to him that it is not entirely obvious on how to set the plug-in up, so in order to help with this issue he has opened up a documentation page, which will be populated.

General Discussion

  • Monty Linden has been itemising some HTTP changes for LSL, “so that we can support things that are less weird and arbitrary”. He hopes to make this a public RFC or a blog post “soonish”.
  • The face count mismatch bugfix remain in limbo, having raised numerous internal questions at LL during code review. Leviathan – was had been looking at it – has also been focused on game_control but will try to take another look at that as soon as game-control is “mostly done” (e.g. server- and viewer-side communication changes, new LSL call, as mentioned above).
    • Monty Linden added that a fix is “very much wanted”, as the current coding around the issue is “interesting”, but he wants the final result to be “absolutely solid”.
  • The request for a llGetRegionWorldMapTile function remains on a “thing that would be nice to get done” at LL, but does not have any resources looking at it at present.

Date of Next Meetings

  • Leviathan Linden: Tuesday, August 11, 2026.
  • Formal SUG meeting: Tuesday, August 18, 2026.

2026 week #31: SL CCUG meeting summary

Posted on by Inara Pey
Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, July 30th, 2026.
  • Please note that this is not a full transcript of the meeting but a summary of key topics.
Table of Contents

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

General Viewer Notes

  • While viewer 26.3 is now available as a Release Candidate viewer, it does not include all the hoped-for performance improvements (particularly with some of the texture streaming work.
    • This was because of time constraints in getting the updates tested across as many hardware configurations as possible.
    • As a result, this work will be held over for the Graphics Care Package (GCP) viewer.
  • The GCP viewer is a lot of fixes and improvements around PBR and correcting issues within it as far as possible. It is hoped that this viewer, which has been suffering a lack of resources, will start to move forward once more in the near future.
  • Various pull requests (PRs) are now being looked at and worked on (e.g. semi-transparent media on a prim), but no guarantees as to when these might surface in a viewer.

Lua Updates

  • There is a new versions of the Lua editor viewer, as noted above.
  • This includes a new version of the VSCode plugin.
    • This has a much tighter integration with the viewer.
    • It is possible to select multiple objects in-world and open them for examination in a Visual Studio panel and then manipulate them (e.g. stop scripts, remove scripts or notecards) subject to permissions.
  • These new features do need to be enabled for use in the viewer:
    • Preferences → Advanced → Script Development → Script Development Settings floater → check VS Code Tight Integration.
Enabling tight VS integration on the most recent Lua editor viewer
  • Rider Linden is actively looking for bug reports on both the viewer and the VS Code plugin.
  • Note that the above does not mean that Lua is grid-wide.
    • Server-side support for Lua scripting remain available only in those regions with the required back-end code.
  • Currently, the hope is to:
    • Have the Lua editor got to beta / Release Candidate status after the 26.3 viewer is promoted to release status, with the caveats again being a) viewer priorities may change; b) at the time the viewer reaches beta / RC, Lua code support in the viewer still may still be restricted to those regions running on simulators with the required back-end support.
    • Have the back-end support for Lua deployed grid-wide “some time” during quarter 3 2026 (e.g. between this meeting and the end of September 2026)
  • Official Linux support remains with the Lua editor viewer as its first release.

General Discussion

  • Discussion on mesh improvements are continuing internally at LL. This is something the Lab wants to get done, but it may not be something that surfaces in the near future. Once the internal discussions have led to decisions, then more details will be put to the CCUG for discussion.
  • The game_control code now might not ship with the Lua editor viewer given the additional back-end work Leviathan Linden has agreed needs to be done (see my notes from the previous Leviathan Office Hours meeting).
  • A demonstration of a means to export scripts from a HUD to an external app to assist with HUD creation / positioning / testing was demonstrated (videos here, here, here and here). The end goal for the project – making it available to others and how, was not too clear.
  • The above led to the subject of SVG support in the viewer being again raised.  This is seen by Geenz as being “something that could be interesting at some point”, but the Lab is “a ways off” of having time for the work outside of MOAP.
    • In the meantime, Callum Linden is looking at MOAP + SVG support and what can be done there.
  • Viewer-native (aka “official”) PBR support for Bakes on Mesh (BoM):
    • Geenz noted there is interest at LL in providing this, but there there are various pre-requisites and consideration to be worked through, together with priority.
    • One example of this is: considering how to combine PBR BoM with Blinn-Phong, with a prerequisite being PBR specular support in the viewer (which is due to be a part of the GCP viewer).
    • There is also some need for work on BoM in general, such as improving elements of the UX.
  •  glTF lights:
    • glTF lights are described as “still a ways out”, but SL is getting radiometric units per the glTF specification for the Sun and Moon as a part of the GCP viewer.
    • Point and spotlights are a “much bigger ask” requiring additional wire protocol work and updating object parameters. As such, there is work in advance which needs to be completed in order to make point and spot lighting “doable”.
  • The above touched on shadow casting, which was seen as a combination of being something that might have to wait for the graphics API / Vulkan work, and as requiring sufficient controls and settings so as to allow users to adjust it for performance on their hardware.
  • A pull request (PR) to add the ability to take screen shots with a transparent background only showing avatars, Animesh, particles from the avatar, objects sat on, and selected objects (eliminating green screens) has been put forward and looks like it is going to be accepted.
  • A question was asked if the consensual system at the Adult Welcome Hub (see my review here) will be made available to content creators for use grid-wide. There is apparently a Feature Request asking for this, and it is under review.
  • Geenz requested that if people know of regions  parcels with pre-PBR EEP settings which look “broken” when viewed on a PBR viewer rather than a non-PBR viewer (e.g. things seem to be unnatural dark or objects are unnaturally glowing, etc., when see on a PBR viewer but not on a pre-PBR viewer such as non-PBR versions of Firestorm), to please for LMs to him for investigation. This does not include PBR EEP settings looking differently on pre-PBR viewers, etc.

Next Meeting

2026 week #31: SUG Leviathan Hour: game_control / region crossings

Posted on by Inara Pey
The Simulator User Group meeting place at Longfellow

The following notes were taken from the Tuesday, July 28, 2026 Simulator User Group (SUG) off-week meeting (the “Leviathan Office Hour”). These notes form a summary of the items discussed, and are not intended to be a full transcript. They were taken from my chat log of the meeting, and Pantera’s video is embedded at the end of this article – my thanks to her, as always, for recording and providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
  • The “Leviathan Office Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
  • Meetings are held in text in-world, at this location.

Game_Control

  • Leviathan has cut a new version of the game_control viewer (v0.7.8). This includes:
    • Per-axis per-mode invert option.
    • Keyboard support for flycamming.
    • Variable speed for avatar rotations when using the game controller stick.
    • Mouse-click actions for Mouselook mode.
    • Mouse mode (ability to control the on-screen with a gamepad.
  • His hope remains to get the game_control capabilities into the Lua editor viewer before that finally goes to release status (which might happen in the latter part of August).
  • However, internal discussions at the Lab have caused Leviathan to realise he needs to overhaul the GameControlInput UDP message format server-side before the code can go out in a viewer. This work will also require a server-side code updates for the simulator in order for game_control to work.

Region Crossings

  • During the week #30 Simulator User Group meeting, Pepper Linden indicated they had put together some fixes to address vehicular region crossings.
  • Those updates have been deployed to the Blake Sea region on Aditi (the Beta grid) for those wishing to test them.
  • Sandbox Wanderton and its neighbours are also going to be cloned on Aditi for further vehicle testing on land.
  • The above work is separate to Harold Linden’s work on script serialisation to prevent scripts from crashing/disabling on a region crossing should be live across the grid in the current simulator release.
  • He also indicated LL is aware of recent region crossing issues within Blake Sea on Agni (the Main grid), which might be griefer related.

In Brief

Please refer to the video for more on the following.

  • As per my week #29 Leviathan Office Hour notes, PromptFont is being used for the game_control preferences UI.
    • It was asked if the tool could be more widely used within the viewer.
    • However, there are no plans to do so because the version in use has been modified for that specific use, with a large number of unused glyphs stripped out that to reduce viewer installer bloat and limit dependency on PromptFont beyond the game_control requirement.
    • The above sparked a conversation on viewer fonts that ran through most of the meeting.
  • A general discussion on the use of AI LLMs for coding.

Date of Next Meetings

  • Formal SUG meeting: Tuesday, August 4, 2026.
  • Leviathan Linden: Tuesday, August 11, 2026.

2026 week #30: SL Open Source UG Summary

Posted on by Inara Pey
Hippotropolis Theatre: home of the OSD/TPVD meeting
The following notes were taken from:

  • My chat log of the Open-Source User Group (OSUG) meeting held on Friday, July 24, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The Open Source User Group (OSUG) meeting is an open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
  • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
  • Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

  • 26.3 is heading towards a beta  / Release Candidate release, but with the texture streaming work removed. The latter will now form a part of the Graphics Care Package (GCP) viewer.
  • The next alpha version of the Lua viewer (with Linux support) is seem to appear “soon” – it is just awaiting the OK to be allowed into the wild.
  • Overall, the viewer release schedule is “a bit up in the air right now”. The hoped-for plan remains:
    • 26.3 issued as an RC and progressing to release status.
    • Lua/Linux progressing to beta / RC shortly after 26.3 releases release status and then itself moving to release. However, this is not guaranteed as yet.
    • On-going work with GCP so that it can be more fully discussed at the next OSUG.
  • Vcpkg (under-the-hood viewer packaging to replace the current Autobuild process used to build the viewer):
    • Currently, LL is trying to figure out where to land this work, but currently it is unlikely to be introduced with the GCP viewer builds.
    • One thought is to try to land it in develop at some point in the coming months.
    • However, feedback was requested from TPV developers relying on the existing autobuild infrastructure as to what they would like as the preferred path towards adoption.
    • Geenz requested TPV Developers should contact him with their views; in lieu of feedback, he’ll also post something on this on Github .

The SL Wiki

From Kyle Linden:

We’re reviving the Wiki. Our goals are improved moderation tools, a theme refresh and it will be the new central repository for Lua documentation, complimenting the LSL Portal in the Wiki. That means we also want to re-open editor access to all SL accounts that have logged in world. Enabling the Wiki to be a Wiki. Along with a more robust moderation toolset we’d also like to have dedicated residents who are interested in helping, be part of the human moderation team. Please IM me if interested.
  • Kyle also noted that the Second Life Creation Portal is to take a “new direction” and that the scripting information currently there is to be migrated to the SL Wiki. 

Other Items

  • Monty Linden noted that Lua/Luau documentation is sparse at the moment, so LL will be leaning on external materials and contributions to support Lua.
    • In this regard, those interested should refer to Suzanna’s SLua Guide, developed by Suzanna  Linn, which includes documentation and details on in-world Lua scripting classes.
  • It has been noted that there is code on the SL Github repositories written around CEF to replace the current plugin model.
    • The advice was given to keep whatever the new plugin architecture might be running in a separate process.
    • Linking directly the CEF library to the viewer was seen as causing issues with memory allocations as CEF/Chromium uses its own allocator; would expose the viewer to all of the vulnerabilities and exploits discovered weekly in Chrome; open the viewer to crashing each time CEF crashes.
    • Additional concerns were raised on this, including the idea that perhaps LL should investigate a means to push CEF updates to all users, regardless of the viewer they are using.
    • Callum Linden indicated that the work in the SL Github referenced is a research project – LL are looking at ways to improve memory and speed + cookie sharing with CEF that would remove some of the issues associated with it. However, the concerns raised were noted.
    • This led to a technical discussion on CEF and how best to approach its use in the viewer- please refer to the video.
  • Geenz noted the work to simplify the means by which developers can contribute code to LL (e.g. shifting from a Contributor License Agreement (CLA) to a DCO – Developer Certificate of Origin) has been on hold due to time and availability, but he hopes to be able to get back to it in the near future.

Next Meeting

July 2026 SL Trust and Safety User Group meeting

Posted on by Inara Pey
Linden Estate Services: Trust and Safety User Group meeting place
The following notes were taken from:

  • My chat log of the Trust and Safety meeting held on Tuesday, July 21st, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The Trust and Safety User Group is to provide a forum to discuss topics relating to safety and security in Second Life. However, please note that for matters of privacy and personal safety, the following will not be openly discussed by members of the team:
    • Reports of abuse, together with the outcome of investigations or actions taken in response; specific account information (including terminations, suspensions, warnings, etc.); DCMA or copyright issues; internal processes; ToS interpretations.
  • The meetings:
    • Are held on the 3rd  Tuesday of the month, at 11:00 SLT.
    • Take place at the Linden Estate Services meeting place.
    • Are a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.
  • For descriptions on all SL user groups and their purpose please refer to SL Official User Groups.

Trust and Safety Blog Posts Blog Posts

  • The Second Life Trust and Safety team shares regular community blog posts to help keep the community informed and educated on various topics. These blogs cover topics such as maintaining strong account security practices, tips and tricks, and helpful how-to guides.
  • All posts can be found within the Trust and Safety Tuesdays section of the Community blogs and are now tagged as such.
  • Those who wish to receive the updates via e-mail can hit the Follow button on the page.
  • Going forward, Trust and Safety blog posts will be made on every second Tuesday of the month (i.e. the week before the Trust and Safety User Group meetings).

Updates from the Team

  • Since the previous meeting, the number of phishing attempts within Groups and IMs appears to have decreased. This is put down to:
    • Greater awareness among users, thanks to word-of-mouth and the Lab’s Phishing blog post.
    • Work the Lab has put into implementing measures on the back-end to more readily address the issue.
    • However, dealing with the problem is still viewed as an on-going effort, including addressing other areas of attempted scamming.
  • To further help combat phishing, it has been suggested that the use of a logo icon with official SL links is extended to include 3rd party sites where there is an established SL presence / use (e.g. Primfeed, Flickr, Gyazo) so that genuine links to these sites can be easily identified when appearing in chat, IMs. etc., and – if possible – in embedded links (those using [] to display them as a word rather than a URL).
  • There will be blog posts in the future focused on Abuse Reports – how and when to file, and what information is helpful.
    • There is also my own Abuse Reports tutorial, which has been submitted for further review by the T&S team (given it is now seven years old), and has been found to still correctly reflect the process of filing an AR.

Abuse Reports

  • There is a backlog of Abuse Reports that are being addressed.
  • However, incoming reports do still get reviewed for prioritisation. Every effort is made to address all ARs in a timely manner wherever possible.
  • In terms of disclosure of personal information – raised at the meeting – it was acknowledged that these can take time to resolve, due to the need to carry out a full investigation and make sure the situation is fully understood and the correct action taken (see below as well).
  • Offensive / hate-related graphics and symbols seen in-world should be subject to Abuse Report filing (with images of the items, if possible).
  • Land encroachment issues (particularly on Mainland) should be AR’d if they cannot be addressed through contact with the owner of the encroaching object(s).
  • A question was asked about Abuse Report categories and LL providing more information on them.
    • Currently, I have a breakdown based on information provided by the Governance team (part of Trust and Safety) – see: Abuse Report Category notes.
  • A reminder was given that while it may not appear that an Abuse Report appears to result in “no action”, this may not necessarily be the case: it is possible that the issue is still under investigation; or that action has been taken, but not in the manner anticipated when filing the AR; or that investigation failed to produce sufficient cause/ evidence for action to be taken; or (at the current point in time) the report is caught in the backlog
  • Even if previous ARs relating to a situation or individual, etc., appear to have resulted in “no action” filing further reports where the actions are repeated is worthwhile as they help T&S built up a pattern of behaviour which can be applied to investigations / actions taken.
  • Note that telephone support staff cannot assist with filed Abuse Reports, as they do not have access to the information, nor are they in a position to file an Abuse Reports on a user’s behalf.

Marketplace Reports

  • These are dealt with by Trust and Safety.
  • It is acknowledged that there are issues with MP reporting – lack of categories, mis-matching between categories and flags, etc.
  • T&S is working with the Web Team to try to improve this, and it is possible that Melody Linden from T&S could attend the Web User Group meetings to discuss there.

Disclosure of Personal Information

  • This is definitely against the ToS / Community Standards and should be AR’d.
  • HOWEVER it also requires forethought from users: whilst there is a “1st Life” tab in the Profile floater (which would perhaps be better relabelled to something like “Further Information” or similar and carry a warning about disclosure), people should take care as to what they place within that tab and be mindful not to put anything which might be used as personally identifying (or indeed, anywhere else in their Profile.
  • Where such disclosure goes beyond Second Life and presents the potential for harm, additional doxing, etc.), the matter should additionally be reported to local law enforcement.
  • Personal Data disclosure with external tools:
    • It was noted that there is a growing use of AI tools in relation to Second Life for the production of images, etc.
    • Whilst LL has no jurisdiction over such tools, a reminder was given that those using them should take the time to read any related terms of service, etc., particularly in regards to collection and re-use of personal information / personally identifying information.

General Discussion

  • A question was (again) asked on what is allowed within region maturity ratings – the clearest answer is via the Maturity Ratings guide. There is also the Adult Content FAQ.
  • There was a discussion on security orb timings, covenants and breaking covenants. This can be a complex subject (e.g. estate  – Private and Mainland) operating covenants which specify how systems systems should be used (contact estate owner); Mainland areas managed directly by LL (e.g. Bellisseria) – raise an AR if the security owner refuses to address covenant violation; security systems that encroach public spaces / rights of way (e.g. waterways and roadways) – AR, etc.
  • The question was asked whether T&S work with third-party sites closely associated with Second Life (e.g. Primfeed), to address ToS violations. In sort: LL have no direct jurisdiction over such sites, and the likes of Primfeed tend to be very well moderated anyway.
    • However, if a post on Primfeed, Flickr, etc., includes an image directly related to something viewable in-world which is against the ToS / Community Standards, then this can be subject to an AR, especially if an identifying location / avatar name can be supplied as a part of the AR.
  • Requests have been made for increased moderation on SL’s Discord channels to deal with spamming, attempted scams, etc. One suggestion is for LL to deploy a honeypot bot to help address these issues.
  • Use of bots / scripted agents / traffic gaming came up:
    • Traffic gaming can be reported via AR.
    • Bots not registered as scripted agents can be AR’d.
    • As it was noted that it is not always easy to tell an “unregistered” bot from a properly recorded scripted agent, therefore it would be useful to add a field to the agent profile indicating it has been properly tagged as a scripted agent, making identification instantly possible.
    • The latter point has been previously raised as a Feature Request, currently being tracked by LL.
    • Policy for reference: Scripted Agent Policy.
  • The subject of linking alt accounts to a main account was again raised “to allow blocking in bulk”.
    • This could be a privacy issue. For example: I might want to have an alt for a specific legitimate purpose in SL (role-play, research) or for business use, etc., and I do not wish to have that account directly associated with my “main” account.
    • Alt linking resulted in one of the most drama-laden situations in Second Life in the early 2010s with the user-created Red Zone “alt linking” system.
    • Obviously, LL have the means to link accounts for investigative purposes.

Next Meeting