Gwyneth Llewelyn

All right, I've been on some sort of affiliate programme since the very beginning, when all you needed to do was post a link to https://secondlife.com with a special code. I'm well aware that is long gone Then I tried adding Google Ads (when LL used it), and CJ, and... well, and that's what I remember, really. It's not like I ever made a gazillion L$ (or US$). But it would be always nice to have 'something'. Even the odd L$ or two would be nice. That said, you can always roll out your own system. According to this infodump-clickbait-infomercial article designed to promote an affiliate service (click on the link at your own risk), there are plenty of open-source alternatives out there. Some even work inside a basic WordPress setup! You could try or test one of those for starters and see where it leads; I wouldn't expect an avalanche of affiliates and the respective users flooding in from those websites (with possibly a very few exceptions...). Some solutions are 'freemium' — you start for free, see how big it gets, and after a certain threshold, you switch to a paid solution. This is often the best way to try everything, of course, not just this kind of solution; after all, if the 'new and improved' affiliate programme is a flop, the last thing you want is to waste money on it. So... start small with very low expectations, analyse whatever data you get, see if it's worth to keep the programme open, and read @GeorginaLux's ChatGPT-generated proposal in order to stay on track 🤣

Ah. I see: it only was in context if you happened to read the whole thread, so to speak, or at least go back a few years to understand why talking about notecard permissions is part of the topic. But if you just read a handful of more recent articles, I certainly can understand the off-topic-ness of the thread. On the other hand, discussing if a thread has some of its posts off-topic or not, is, by itself, being off-topic, although one might argue that discussing off-topic-ness is, in a sense, meta-discussion, and, as such above and beyond the possibility of being off-topic But one might also argue that meta-discussions, and the philosophy behind meta-discussions, ought to be pushed into its own topic of, precisely, meta-discussions, like some platforms already do (Wikipedia and Stack Exchange both come to mind). Pfft. What are 4 years in the history of Second Life? A mere snapping of the fingers. Good issues that require fixing/addressing are at least a decade old, if not two 😏 (a good reason to get rid of JIRA, IMHO) That said, I was never a fan of closing a thread just "because it's too old". What matters is if the issue is still relevant or not. And I would say that, as far as I know, the original problem hasn't still be addressed — i.e., how to be sure that a request comes from Second Life's servers in the SL Grid and not from anywhere else, especially if we cannot rely upon things like physical IP addresses (since those are, these days, merely virtual machines on the Amazon cloud)? The only solution I've come across so far are those being addressed on the Feedback Portal: https://feedback.secondlife.com/scripting-features/p/sign-outgoing-lsl-https-requests-for-verification https://feedback.secondlife.com/feature-requests/p/use-a-well-recognized-ca-for-simulator-https-listeners These are "feature requests" which do not quite propose an actual mechanism, but the principle is essentially the same: make in-world calls be made with client certificates which we can authenticate as coming from Linden Lab. This should be the best, or at least the easiest to implement, most secure way of handling the whole thing. It is also backwards-compatible, i.e., if you don't wish to check for the authenticity of the requester's client certificate on your own backend server, you're free to ignore it, and nothing will break; thus, "old" scripts that didn't validate the origin of such requests will continue to work, no matter what additional certificates they now present. There are a few alternatives that come to mind — all of which requiring LL intervention, of course, and increasing levels of complexity in terms of additional development — but I'm not quite sure if those could degrade gracefully to the current system. For example, imagine that LL would have some sort of central token registration database (or use one from a third-party). Every time the script calls an external URL, it would first authenticate itself with that central token registration database, and, well, get a token. This token could then be sent on the request header. Upon reception of the token, the external server would now attempt to contact the central token registration database (CTRD for short) to see if the token was really one requested by LL or not; once a positive reply has been received, the token would be 'consumed' (i.e. removed from th CTRD, or flagged as expired). A "premature deletion" (due to some sort of mistake, network lag, etc.) would not be a problem, you could always get another token... But I guess this would take longer to implement, and I have my doubts if it would even be "better" and "more secure" than the client certificate alternative...

Well, the whole point of 'this conversation' was to figure out alternative ways of confirming that a request originated legitimately in an object inside SL without relying on the domain name and/or IP address... originally, Oz Linden proposed using a shared secret to do a bit of signature-signing. However, that required the shared secret to be in plain text, which made things hard in those situations where everybody is supposed to be able to look at the script. We went through several suggestions, and my own — which I'm glad to retract, since apparently it's easy to circumvent — was to store the secret inside a notecard, separate from the script. What exactly in the above paragraph as "nothing to do with the main topic of this thread"? Isn't the "main topic of this thread" discussing alternatives to the reliance on domain names/IP addresses to validate an in-world request?

Almost over now

http://streams.turbodj.com:8238/ if you can't/don't want to attend... You'll miss the always-fun chat, though

Well, I guess that depends. The last time I checked, if the object is non-mod and the notecard is non-mod as well, then not even the (current) owner is able to read the notecard inside. Since the object is non-mod, it means you cannot take anything from its inside, or see it, or drop a script inside to read the notecard. At least, that was what happened the last time I've checked. There might be a case where the two residents (creator and current owner) belong to the same group — if the object is set to the common group, then the owner might be able to read the notecard, in one way or another (group-specific permissions may also apply in this case). Additionally, if the two residents have allowed mod permissions to each other's content, then the owner might be able to read the notecard, or, at least, be able to drop a new script inside that reads the contents of the notecard. And, on top of all that, there is always this even crazier permission-buster system, which allows new owners to sometimes set the object for sale and buy it for L$0, which will reset some permissions — probably not all of them, but enough to be allowed to drop that magic script inside which will be able to read a non-mod notecard... But... I'm not quite sure if I ever made this kind of exhaustive testing for all possible edge cases. What I can say is that the normal behaviour is that non-mod notecards placed into non-mod objects will not be readable, not even by the new owner. And since that object is non-mod, you cannot replace anything inside, or remove the content in the object's inventory, or add anything new to the current content: it is supposed to work like that (minus any quirks, bugs, or some extreme edge cases).

The 'problem' here is avoiding storing shared secrets in plaintext, on scripts that are meant to be open source (or at least freely distributed between a creator and their direct users, which might not be the ones eventually buying the scripted object). My idea was to store the shared secret in a notecard that would be unreadable to residents, but not to scripts, similar in concept as a file stored on a web server might be freely read by an app running on that same server, but cannot be retrieved via HTTP — such as, say, placing configuration files stored in a directory which is explicitly set as 'hidden' from the webserver itself (a similar concept is using something like .env to store secrets in environment files and explicitly configuring the webserver to refuse to retrieve anything starting with a single dot in its name). I guess that this cannot easily be replicated in SL, since you can prevent a notecard to be read by the resident, but you cannot prevent them to place the notecard on their own objects and run their own script to read the notecard and expose its contents. Thanks for pointing out what should have been obvious for me, but it wasn't I guess that I have to rethink this approach, then.

... as for the "multiple redirect" issue, well, search.secondlife.com is an alias (CNAME) to a service provided by Akamai, which acts as a Content Delivery Network — it will route traffic to the physically nearest pair of devices (I call them "pair" just because they have different IP addresses; on many cases, each IP address might map to several different servers, but they will all reply from the same IP address). Now, these addresses correspond to servers scattered all around the globe on many, many different data centres, where Akamai co-locates their servers. In general, each will have an IP address allocated by the owner of the data centre, so Akamai does not have real control over the IP addresses that get assigned. Also, Akamai may shuffle their servers around, even within the same country, switch providers and so forth, so you cannot rely on these IP addresses to be fixed and constant for all eternity. The clever bit is that Akamai's DNS servers will reply to a request with a different address, depending on where the request comes from. As such, different people, located in different geographical reasons, will see a completely different set of IP addresses (and none of the others). If, by chance, one server — or an entire data centre! — is offline for some reason, Akamai will quickly switch the DNS address resolution to the next-to-nearest set of IP addresses. Ultimately, that's the whole point about global cloud services — you're not supposed to know where exactly the cloud-based server is currently located — it may be arbitrary and random (good for security and resilience, but not optimal for performance), or always redirected to the nearest server (good for performance, less so for security, while resilience can be dealt with easily enough, if you have a graph/map showing where all servers are physically located, and can easily figure out where requests are coming from and where they should go if the nearest location is not available). Additionally, I can imagine that Akamai will also route traffic to servers that might be slightly further away, but which may not be congested. It's a trade-off: what is better, routing a user to an overwhelmed server (which responds slowly), but with a shorter round-trip time; or use a slightly longer path, thus with a longer round-trip time, but potentially handling much less traffic, and therefore probably replying quicklier? The decision is not really "either one or the other approach", but requires a small algorithm to figure out what is "best" for a particular scenario. The point here is that it's really not worth the time spent in 'discovering' all the IP addresses of the Akamai servers. They will inevitably change a lot over time (as Akamai adds more machines, or opens up new data centres, or changes provider...), and, unless they release some sort of API telling which addresses they're using (some providers do that; I haven't checked with Akamai, though; and it's also possible that accessing such a list is for customers only), it's pretty much next to impossible to track them down and keep them updated. Granted, I'm writing this in 2024 🙂 Things are prone to change all the time. For instance, if LL uses a lot of Amazon's AWS services, why do they stick to having Akamai as a front-end to their search engine (wherever and whatever it is running — I tried to figure it out, to no avail)? Well, as far as I can see, LL's servers are mostly located in just one Amazon data centre, namely, the one closest to them. They might prefer to keep their core services on AWS, while using Akamai for world-wide distribution. There might be a good reason for that (e.g., financial).

Piping in two months late... For those worried about plaintext shared secrets directly on LSL scripts (as Oz Linden suggested) that might require to be open source, or distributed full perms, one very simple way of avoiding that is to write the shared secret in a notecard, and make the notecard non-mod (and therefore unreadable to others that have no permissions to edit your objects) but free to copy/transfer. This would allow those cases where the recipient of the script is expected to use it inside their own items (for example) and eventually sell these with the script inside — as well as the notecard. It's a simple way which emulates the way people store plaintext secrets on web servers — the secret is not hard-written in the code itself, but rather comes from an environment variable, or possibly from a protected file which cannot be read by the web server itself. Of course, this continues to be a security problem in the sense that if the notecard is ever compromised, everybody will now know the shared secret. To make it a bit more complex, you would need to go a level deeper, and provide a way to invalidate existing notecards and send one with the new shared secret. If we could write notecards programmatically (like we can in OpenSimulator!), the issue would be much simpler to solve. But notecards can only be manually created. Having a Subscrib-O-Matic kind of service that sends new notecards to everybody needing it is easy to do. It can even be done semi-automatically: when, during the HTTP transaction, the server notes that the message came with a deprecated/cancelled shared secret, it instructs a delivery box to send the requesting object a new notecard, and possibly alert the object's owner that the 'license key has expired' (or something like that) and that a new one is on its way. Sadly, there are also some limitations in delivering notecards directly to an object — you can do it, but only if both the origin and the destination objects are near to each other (in the same region, I believe). Personally, I'm not quite sure on how to do a more complex system that is unbreakable but at the same time open-source (in the sense that, even though anyone may see the script, or even tweak it to their tastes, they cannot 'break into the system', i.e., access resources they are not supposed to) and easy to manage. I mean, I'm essentially describing something akin to a Public-Key Infrastructure, or like PGP Alas, doing that in LSL (or an equivalent system!) is certainly not a trivial exercise. The closest I can think of would be to have something like a centralised registry in LSL which would have a key/value store, indexed by UUID of the avatars participating in the system, and storing the shared secret currently valid for that user. Running in-world, there is no way to "forge" messages, but there is also no easy way to communicate between objects. Also, this would quickly run out memory, for popular services. Hmm. Maybe it's worth thinking about how to implement such a system. So far, all the ideas I came up with are relatively easy to break (so I'm sparing you the trouble of explaining them, lol), or, at best, don't improve vastly on Oz Linden's suggested script...

Look, the whole process of acquiring items for your avatar to wear is insane. It draws from so many different sources... For instance: as soon as LL comes up with some technical innovation, content creators turn it into fantastic things. However, that isn't always straightforward. In the ancient days, LL thought that they could get away with merely having painted textures on top of avatars. Okay, so, well, people wanted to wear jackets over T-shirts over their underwear... so, LL introduced many 'clothing layers' and changed the viewer technology to pre-bake your avatar's 'whole texture' (actually, three — head, top, bottom) and send it to everybody else, as opposed to sending all the textures separately, and allow each viewer to bake it independently (which didn't work that well). Then we started getting transparencies — of two different kinds. Then LL toyed with the idea of having materials (we had about a dozen or so) but abandoned the plan. By this time, people were already wearing prim shoes and prim hair — because you simply couldn't do anything very realistic by just painting textures over your body. Prim clothing brought a bit more tridimensionality to clothes, but it also meant that avatars were starting to wear things constantly, which was not quite what LL originally had in mind. Obviously, I don't know what these ideas were, but you can get some hints from very early movies of SL. It's clear that "valid attachments" were things like weapons or a jetpack or any kind of discardable items, to be used in some sort of "experience" or "adventure" or "game" or... whatever... but not exactly something that was supposed to be permanent. Still, that's what people started doing — 'permanent attachments' which were used, well, as part of your body or your clothing. Which, in turn, meant that you would now have items in your inventory that were yellow cubes but were not 'regular objects', but rather 'clothing' as well. That started to become... confusing. And from there, we jump to flexiprims, to rigid sculpties, to mesh (in its many variants!), and, ironically, 'bake on mesh', which is sort of how it all began... but on a completely different avatar body! All of that is now spread across over inventory, of course, and it's all small yellow cubes. You just need to figure out how to set them apart from, well, objects. It's a bit easier if you read & write English with some fluency, of course, since the vast majority of items will be labeled in English. Okay. Now that's the positive part, so to speak: content creators incorporating new technology into their creations, and doing more and more things that LL never even remotely dreamed about. Then we have the dark side. These are all the very complex tricks that content creators have to come up with to deal with technical limitations imposed by LL — for whatever reason — and figure out ways of working around those limitations. Here is an example: buying things. The way it was designed to work was simply to put your items inside a prim and set it to sell its contents on touch. Easy, right? The problem is that if you have dozens of items to sell — and each in different colours, too! — that's a lot of prims, and that's a lot of tier to be paid. Therefore, vendors became popular very early on, because you could just use 2-3 prims and let customers search through all your clothes. Unlike selling a prim's content — which does not require any scripting at all — vendors are slightly more complex items. They need a bit of scripting to shuffle textures around and deliver the item currently selected after receiving a confirmation of payment. And here the problems start: while, script-wise, you do get a special event confirming that a payment was made, as well as showing up on your transaction logs, and you can then proceed to send an item to the buyer (because you know you've received payment!), you cannot know if the item was ever delivered. In fact, once the item is sent to the buyer, you don't have any more information about what happened. The buyer might have crashed, and the payment went through — but they never received the item. Or they might have a very cluttered screen (most of us do), and fails to click on the dialogue box to accept the item (and it times out). Or you might simply click on the wrong button for whatever reason, cancelling the delivery. Or... well, you can see how tricky this is, so many things can go wrong. All that could have been avoided if LL added just a line of code to confirm that someone received the item! So, what did content creators do? They devised this two-step (and currently three-step) mechanism to guarantee that you really got the item. First, you receive a box, which started as being styled as a "gift box" which you dropped on the ground to unpack. Besides the cuteness of the experience, the important thing is that, once that gift box is rezzed, the script inside can immediately notify the merchant who sold it — they now know that their item was delivered, and was delivered to the right person, and they have it in their inventory (so, they can complain, but the merchant knows that they cannot complain that they didn't get anything!). Dropping boxes on the ground meant owning your own land, or using a public sandbox, or, well, some very brave merchants even allowed customers to temporarily rezz their boxes on the floor of their shops — but, naturally enough, griefers immediately abused that, by bringing their scripted griefing tools with them and creating havoc. So — either you had your own place (and that meant you couldn't even test whatever you've bought until much later...), or you went to a public sandbox, avoiding griefers left and right, just to get your little item out of the box. And at the end you'd get two yellow cubes in your inventory — one was the box, the other was the actual item you've bought. With luck, the content creator had thought well in advance and made it clear which is which. Some, however, just named the item inside with the same name as the gift box. Confusing. You'd delete the wrong one — or kept both, just in case, and were constantly attaching the box to your avatar's head, not the item you bought. So confusing! Later, this was slightly improved with the "shop bag" kind of idea, i.e. instead of rezzing a prim, you'd attach the prim to your avatar. That works as well (and technically you can even use the same script for both cases, so if someone rezzed the handbag in a sandbox instead of attaching it, they would still be able to get the item inside), but with two catches. Some misguided content creators required the "shop bag" to be touched to activate it (as opposed to immediately sending you the item when you attached it). This is usually okay... unless the item gets wrongly attached somehow, and you cannot see where the bag is (maybe it's upside down, floating over your head or under your feet, or even rezzed inside your avatar's body). You might now need to be an expert in turning the camera around just so in order to find where exactly the bag is and touch it on where it's supposed to be touched (sometimes it's just part of the bag that can be touched... it all depends on the content creator's whim). The second catch is that formerly you could just attach one item per attachment point, and that meant that if you were extremely unlucky with the choice of attachment points, you could wear the bag and lose your clothes — or part of them — and it wouldn't be immediately obvious what went wrong — or, worse, you might not even see what was 'displaced' by the bag and cannot remember what you had there before. Not to mention that, on laggy areas, buyers might not see the box or bag being rezzed, and so rightfully complained to the merchant, who had a confirmation of delivery and therefore might not be very willing to replace the item (or perhaps have no time to answer technical support questions related to the user interface...). Also... everybody would know what you have bought by just looking at the box or bag. That's fine if you buy a plain vanilla piece of clothing. But perhaps you're not that fond of showing off that you've just bought the latest 'sex toy' for your private dungeon. No privacy! Confusing? Aye, quite so. It only gets worse, of course. Content creators then realised that, in order to avoid boxes not being rezzed, the easiest way would be simply to send people a HUD, and — hopefully — add some short explanation of what to do with it (i.e. "wear me to unpack"). Cool — no more privacy issues for sure, and no need to worry about where that attachment went. But it also meant that, unless you know what to expect, all of a sudden you might get a huge prim blocking your view which you haven't a clue about (since content creators will use the highest-resolution textures they can, and that means these will take time to rezz — and be just a very blurry obstruction on your vision during that time). It might also displace one of your favourite HUDs, too, making things even more confusing. But now the horrible mess really starts. Very early on, content creators figured out that if they placed scripts in their items, these could be used to enable lots of interesting things. For example, heels could be scripted to play sounds; clothes could change colour; bracelets could be resized without the need for selling them with modify permissions. That was cool in itself, but what was even cooler, was the ability to also script the items to inform the merchant that they weren't merely delivered (which you got from the HUD attachment), but actually used (which you got when attaching the bought item to your avatar). Not to mention, of course, whatever other metrics the merchant would be interested in — but let's not go that way! Initially, those items would be programmed/configured using text chat commands — first in public chat (argh!), later on private channels — but they were sort of awkward to use (if I got L$1 for every time someone typed /ao on in public chat or even on group chat...). Content creators moved on to complex dialogue boxes instead, but, due to the extreme limitations (and awful aesthetics) of those, they quickly moved on to... HUDs. HUDs, mind you, are a tribute to the imagination, creativity, and technical prowess of content creators. Most of them (and there are tons of varieties!) work really well, they work all the time with next-to-zero bugs, and they get more complex every day. Some have extensive manuals and video tutorials, attempting to explain most of its features — a list that grows and grows, to the point that the most complex systems out there have multiple HUDs. I'm obviously talking about the crème de la crème items on the market — coming from the creators of Bento mesh bodies and especially heads — which sport the most complex and thorough set of configuration possibilities, literally layers upon layers of things you can do with your item, all of which fully scripted, and being able not only to interface with your HUD, but also with the HUDs of others — so long as you have them properly configured, of course. And some of them play nicely with your animation overriders, and vice-versa, animation overriders can also 'talk' to your items and 'make' them 'do things' (think couples dances, hugging & kissing, and so forth). The proliferation of different Bento mesh bodies & heads (even if there is a clear market dominance of a few) means that content creators working with apparel and avatar accessories will need to support all those different types — or, at least, all those who dominate the market. Shoppers, on the other hand, need to figure out which kind of content they're supposed to buy for their avatars — and understand why something designed specifically for one type of mesh body will very likely not work on a different type. You have to learn to deal with mesh, rigged mesh, and fitted mesh — and understand which one is appropriate for your particular mesh body. Also, you need to understand that most content creators will expect their customers to know what they're supposed to be buying. Fortunately for us consumers, it's customary to sell multiple meshes (for the different body types) as a single item, so that, when you switch mesh bodies, you can still continue to use your favourite item of clothing. But... sometimes, it's not obvious to figure out which is which. If a merchant sells an item labelled as "Maitreya only" what exactly does that mean? Oh wait, Maitreya just has one female body, right? Wait, no, there are two... there is Lara, and there is Lara Petite. Will they work with the same type of clothing? And now there is also a new Lara, Lara X, which is not compatible with the "old" Lara, but every existing Maitreya customer is entitled to get the Lara X for free, so the content creator can assume that "Maitreya" means "one of the two, just pick the correct body type when using this dress"? What about, uh, Lara X Petite? And there is also the free and open source Ruth 2.0 project, which nobody uses (except on OpenSimulator-based grids, where there is nothing else), but which is sort of compatible with the original Maitreya Lara, but not with the Lara X... That's cool — the content creator says — but you have a Lara mesh body, you also have a Lara X mesh body, so I only need to include one of those in my vendor. It's, well, just "Maitreya" for me. You, the buyer, just need to make sure you're using the right mesh body. Aye, that's all very fine, but what about all the former content which I have, predating the Lara X, and which will work only with the "original" Lara? Some apparel designers are kind and generous and willing to give you an additional Lara X-compatible version of their items, also for free — but this is neither widespread, nor even mandatory. The reverse, however, is not true, i.e. there are lots of content creators doing their designs only for the Lara X, and refuse to do it for the Lara (this has mostly to do with the style of their apparel, which will work only well with the oversized hips & bottom and those meshes that are specifically designed to allow them). Note that this "size mess" is not new. When mesh became popular, content creators sort of agreed to do five meshes in different sizes, so you could pick what would fit your avatar's shape best. Only, like in real life, the measurements were not really a standard, and each content creator had their own ideas of what a "size S" or "size XL" was. In most cases, since you got all five sizes packed into the delivery box or HUD, you could just experiment and see what fitted your avatar best — not unlike what we do iRL when we're unsure about the sizing used by a brand we're not familiar with. But, well, it wasn't exactly easy. With full Bento meshes, things are a bit easier in that regard — just to be more complex on other areas! I trace this whole sizing issue back to the days when Tinies began to be popular (requiring special skeleton-deforming animation overriders) — around 2005. It was conjectured that this "fad" would not last long, because all content had to be redesigned to fit Tinies. That, however, didn't happen. Famously talented top content creator Damien Fate launched their "Loco Pocos" line of cuddly Tinies, which were actually very reasonably priced (for the time), because he hoped to make some real money selling all the clothing and accessories that he made for those Tinies — and sold in (almost) exclusivity through his shop. Such concepts were seen as not having a future... but here we are, almost two decades later, and while "Loco Pocos" has been long gone from SL, Tinies continue to be around, have their own body meshes, and specialised clothing, furniture, vehicles, houses etc.— all made specifically for them. So, as a buyer, you have to be sure you get the content which is appropriate for your avatar, and learn (sometimes the hard way!) what kinds will not work together at all (or only very, very badly). All right. Anyone who is reading this is familiar with all the above, and much more. At the time of writing, Firestorm was still alpha-testing the new renderer (the one that works with PBR Materials), and since that's the most-used viewer to connect to the SL Grid, content creators have been reluctantly releasing some of their more recent items with the ability of using PBR materials as well. Most SL residents cannot notice any difference — only those sticking to the Official SL Viewer will get that awesome experience — but it's fair to say that content creators have been preparing for this dramatic change since late summer 2023. And that, in turn, means new things to learn to configure; new HUD options or even new HUDs; new content overall, which might get revamped and more sophisticated, and more difficult to configure; and so forth. Consider all the above and think of all aspects of the daily usage of Second Life which consists in selecting the correct overall configuration for your avatar. I mean, it's not just point and click, or drag item X on top of your avatar — as we used to do when clothes were just a texture, showing in Inventory with obvious, easy-to-identify, coloured icons. "Configuring your avatar" — playing dress up, if you wish — is, today, an exercise in complexity beyond belief, and it just gets worse and worse with each new generation of content that gets released. ... and you're still questioning why new residents "don't get" the inventory...? Second Life, these days, has very likely the most complex user interface ever designed for a 3D virtual world environment — a design which Is not "imposed" upon us by Linden Lab, but rather by the community of residents themselves. LL is to blame for many things (notably for the way they do not allow us to change the item'd ico

All I can say is that I seriously hope that, once the closed alpha testing with Premium Pro residents is deemed to be finished, there is a closed beta testing with regular Premium residents 🤣 Especially those who have been faithfully paying for their Premium account for the past twenty years (well, 19½...). <hint, hint>

@Marcthur Goosson as mentioned briefly by @arton Rotaru, the extra blue is kind of a "feature" in the sense that it's a "well-known" issue, fully documented on the SL Wiki by the Lindens themselves, and I quote: So, essentially, the blue sky tints everything blue, because... the sky is blue 🙂 One wonders if you could somehow compensate it with a local orange light (being the complementary colour of blue). Or maybe by tinting the sun orange?...

Aye, two excellent reasons for allowing video uploads 🙂 After all, LL already limits uploads to 4.88 MB (at the time of writing) — this would be a good way to minimize abuse and leave videos at a manageable size. Then again, I've noticed that, at the bottom of the screen, it now says: Accepted file types: gif, jpeg, jpe, jpg, png, webp Yay for including WebP (love the enhanced compression!), but there are so many more file types that would make a lot of sense (think HEIC or AVIF), now that we're starting to see HDR implemented in SL

@Nalates Urriah Honestly, I wish I still had the massive amount of free time I had in the olden days Where is all that free time gone, I ask myself?... Oh well. I guess it's just old age; I'm not 30-ish any longer... @Love Zhaoying naturally enough, you're right — there is not really a "standard" per se, and each community forum does things differently, and gives their users more or less formats that they can upload, within certain limits. I'm not questioning that. I was actually just asking if, by any chance, these community forums (and not any others) supported video uploading as opposed to merely embedding them.

This just shows why the next item in line for LL's rendering pipeline is... the terrain 🙂 I mean, to my untrained, un-artistic eye, the only thing I can say is that the SL item looks slightly more dull (but that can be due to the lighting, not how the material reacts). But the terrain — oh my. LL really, really needs to put some serious effort there! (Note: I'm well aware that they are working on PBR materials on the terrain as well) - Gwyn