• friends saga: implement join channel function
• chat saga: /join chat command with channel name
• unity->kernel message: join channel with channel name
• kernel->unity message: confirm or err on join channel

Here's an odd case reported from someone in the community.

After adding a simple 3d model (that wasn't too heavy), the scene could no longer be deployed. The preview works, but not the deploy. If he removes the model, the scene deploys fine. The model weighs 2.56 MB, and the scene has +100 parcels, so it's not going over any limits.

The person asked an artist to edit the 3d model for him, and after that, the scene could be uploaded. He doesn't know what the artist changed for it to work. Neither do I, but I'm attaching both versions of the model to check what changed in the middle.

Whatever problem this original model had, would be good to understand what it was, to either fix or at least show clear error messages of why the model won't work.

The reporter is Doug | NFTWorld.io#0519 on Discord

Broken model:
https://app.zenhub.com/files/337227404/030ede42-19e7-41b7-8ca9-c9dac17b4680/download

Fixed model:
https://app.zenhub.com/files/337227404/22e34687-3df3-4d6c-9c07-639462266b4a/download

Simple scene using the fixed model:
https://app.zenhub.com/files/337227404/1566cb03-dd89-4f03-a234-0b37a85d59b8/download

Extra info from the creator:

I paid a modeler, wont mention their name, who fixed the ship but wont tell me how they fixed it. I wanted to send over the corrected version to you, in case you/your team can track down the issue in case there's a fix for it within the platform. I cant imagine I'm the only one who will ever buy models on sketchfab.com and then have trouble deploying them.

I found this. When I resize one of the images in the model using photoshop, it causes the hash issue that prevents the scene from deploying

https://images.zenhubusercontent.com/337227404/846f77a4-ab0a-48ab-8f4d-cca043d4aa38/recording_574.mp4

Replacing it with the original image fixes it
Not sure why photoshop is causing this hash issue. Figured I would pass this along in case you or your team had any additional insight. Obviously I would like to reduce sizes of images in models that arent necessary. In this case the ship is too high in the sky to see the guns so the gun images dont need to be high res so it'd be nice top be able to reduce them to decrease the file sizes

https://images.zenhubusercontent.com/337227404/3fe27879-9869-49e8-840a-632c503c67b8/recording_575.mp4

I wanted to see if the nodes were what was causing the model to show as bright white in-world, but I cant deploy the scene after removing the nodes from that model

Some profile pictures missing

Cliking on the passport of those players

Steps to reproduce:

• If you have a long list of friends, open the friends section.
• If not, go to the voice chat panel in a crowded place

https://twitter.com/opaaq0/status/1552973365987639296?s=21&t=bRBmXqp172JDbS9q99e9iw

The list of candidates is zero, cannot read property catalystName of undefined

Improvement and not mandatory FTTB.
Avoid sending notifications to renderer when this is configured.

• Message from renderer to kernel to flag a channel as muted
• Save and load muted channels from profile
• Avoid sending message notifications to renderer when channel is muted

I detected a memory crash on kernel-side (not on the renderer/client side) that happens deterministically when following these steps:

1. Access https://play.decentraland.org/?NETWORK=ropsten&position=64,-64&LOS=6
2. Notice that LOS=6 or the "Scene Load Radius" in the settings panel has to be 6
3. Follow this path accross several scenes in our ropsten hell-map:

4. As seen in the video, at the end of that test run kernel crashes because of memory and the console is wiped. That memory crash also disconnects the kernel from the renderer.

Notes

• This happens with or without asset bundles
• This is not a memory crash of the renderer/client like most of the memory crashes we experience, since this was discovered using the Desktop Client (where the Scene Load Radius 6 is more commonly used, instead of 4 as in the web client), and when the memory crash happens, kernel crashes and the desktop client gets disconnected as its websocket connection is interrupted, the client doesn't crash.

• Renderer->kernel message to load friend list (paginated)
• Kernel->renderer message with friend list (paginated)
• Friends saga implementation

What?

The voice chat is not working correctly on Firefox. Once we press the T key to talk, the icon state is correctly updated to green but no audio is sent, and if we unpress the T key, the icon keeps actived (in green) forever.

• Once we press the T key to talk, we have checked the SetVoiceChatRecording(true) message is being correctly sent from Unity to Kernel.
• After that, we see the next warning message in the firefox console: "Actualmente no se admite la conexión de AudioNodes desde AudioContexts con diferentes frecuencias de muestreo.".
• Once we unpress the T key, we have checked the SetVoiceChatRecording(false) message is being correctly sent from Unity to Kernel.
• After that, we never receive the SetPlayerTalking(false) in Unity. For that, the icon is never being updated to red anymore.

Steps to reproduce

1. Enter the world with the Firefox browser.
2. Press the T key to talk.
3. Notice the voice chat icon in the taskbar is activated (green color) but if you talk any audio is sent.
4. Unpress the T key.
5. Notice the voice chat icon keeps actived forever.

• Renderer->kernel message to load friend requests (to and from current user) (paginated)
• Kernel->renderer message with friend requests (to and from current user) (paginated)
• Implementation in friends saga

When working on trying to solve issue #37, I realized that not just voice chat is working poorly on Firefox, but also scene code.

It seems there is a significant performance degradation in Firefox starting from version 90, and that it is related to a delay when sending messages between web workers. This may be a Firefox regression, or it may be a consequence of a security update or something similar. In any case, further investigation is required.

To test the degradation: Firefox 89 can be downloaded from here: http://download.cdn.mozilla.net/pub/firefox/releases/89.0.2/. You can compare its performance (which is not stellar, but is somewhat tolerable) with the latest release.

I was debugging the unity-explorer issue decentraland/unity-renderer#2432 and I realized that this might be a kernel bug.

Basically when we create a new guest user the name we pick in creation is always overwritten by a random name picked casually and the email is always empty.
I'm saying it might be a kernel issue because in the messages we receive after the character creation and after we send correctly the message SendPassport with new name and email, the first message we receive of type LoadProfile holds the correct information, then there is another LoadProfile one that has wrong info, following the two payloads received.

First correct one (with no mail):

{"userId":"0xdf00299f60ac4c0f6cf9e91692f6bc29e1f235a5","email":"","version":2,"hasClaimedName":false,"ethAddress":"0xdf00299f60ac4c0f6cf9e91692f6bc29e1f235a5","tutorialStep":0,"name":"TestUsr#35a5","description":"","avatar":{...

Second wrong one (with no mail):

{"userId":"0xdf00299f60ac4c0f6cf9e91692f6bc29e1f235a5","email":"","version":2,"hasClaimedName":false,"ethAddress":"0xdf00299f60ac4c0f6cf9e91692f6bc29e1f235a5","tutorialStep":0,"name":"Lujube#35a5","description":"","avatar":...

Also after pressing the "Got It" button in the first screen that appears i receive another LoadProfile message that again is with the wrong name and has the version 3:

{"userId":"0xdf00299f60ac4c0f6cf9e91692f6bc29e1f235a5","email":"","version":3,"hasClaimedName":false,"ethAddress":"0xdf00299f60ac4c0f6cf9e91692f6bc29e1f235a5","tutorialStep":256,"name":"Lujube#35a5","description":"","avatar":

Debug and analyze why voice chat works on some setups and not in others

Notify status updates to Marja

This section in particular seems out of date: https://github.com/decentraland/kernel#running-the-explorer

and a general update would be very appreciated. Thanks a lot!

• Add a type to the ChatMessage type for CHANNEL

We have observed some cases in which there is people that can see everyone and that seem connected to the P2P network, but other people cannot see them.

Previously we've seen that this happened when a profile couldn't be loaded correctly. Preliminary investigation seems to indicate there is something wrong in the logic that loads profiles:

• The user that couldn't be seen did appear in the "known peers" of the peer library, and its stats seemed to indicate that messages were being received. This was checked using https://peer.decentraland.org/comms/peers to translate the user's address to a peer id, and seeing the known peer Object.values(__DEBUG_PEER.knownPeers).find(it => it.id === "${user's id}")
• The user's profile didn't appear in the global store. This was checked using: globalStore.getState().profiles.userInfo["${user's address}".toLowerCase()]

This seems to indicate that the profile couldn't be loaded, and for some reason is not being retried either.

And deprecate tslint

When the user receives a new private message and the user profile has not yet been sent, we have to notify it.

Since the introduction of archipelago

When changing wearables, it is expected that other people can see the change immediately. This was the case up until recently, and it is still working for guest players (without wallet). But currently is not working anymore for wallet players.

Steps to reproduce:

• Have two players find each other in world. At least one of them must have connected wallet.
• Have player 1 (connected with wallet) change a wearable
• See that the wearable changes in the screen of the player 1
• See that the wearable doesn't change in screen of the player 2

Additional details:

• If any of the players refreshes the page, the wearables will be displayed correctly
• Guests can change wearables correctly without issues.

there are some workers con kernel that could be moved to their own repository

• Gif Processor
• VoiceChatCodec

We must understand how are scenes behaving in order to find the places that can be enhanced, polished, reworked

• unity->kernel message: search channels
  • # page, # results per page, filter
  • possible filter already joined channels
• friends saga: search channels implementation
• kernel->unity message: result of search channels

• From last message to previous
• Renderer->kernel message to load chat messages for a given conversation (paginated)
• Kernel->renderer message with chat messages (paginated)
• Friends saga implementation

A new functionality will allow players to set an home point to let them spawn there.

The changes that are currently needed in kernel are:

• A function that the unity renderer can call to which pass the home point coordinates (it was suggested to save this coords in the local storage and avoid saving at profile level)
• A function that the unity renderer can call to retrive the current home point (returning 0,0 if not set)
• The behavior of this should be that if in the URL there are no specific coordinates the player should spawn at the home point, otherwise the url coordinates will override this

For additional info this is the unity-renderer issue: decentraland/unity-renderer#2021

Right now they are part of kernel. All contributors may leverage a better developer experience if that were removed from kernel and uploaded to a static CDN.

When logged in Decentraland, the current user needs data from the profiles that are near. To do that, the Explorer is currently getting the info per profile through GET /lambdas/profiles/<PROFILE_ID>, when there are many users in the proximity zone then those are too many requests.

The Lambdas API already has an endpoint that supports sending many (with 50 max) profiles at once: GET /lambdas/profiles?id=<PROFILE_ID_1>,<PROFILE_ID_2>.

We need to modify the Explorer to use the new endpoint to reduce the number of requests to the Lambdas API.

Also, we need to check if the correct path forward is doing this change in the Explorer or directly on the Unity side.

Description

In order to support Third Party Wearables (or Linked Wearables) in the backpack, we need to add a query parameter to the Wearables request.

Catalyst Lambdas service will add an optional collectionId query param to /wearables-by-owner endpoint:
/wearables-by-owner/:owner?collectionId={string}

• Avoid loading messages for all friends
• Adapt friend initialization message (kernel->render interface) to only send unseen notifications and new friend requests notification number to Renderer

For regulatory and security reasons, every instance of kernel should configure a single content server regardless the comms catalyst

• friends saga: implement leave channel function
• chat saga: /leave command with channel name
• unity->kernel message: leave channel with channel name
• kernel->unity message: confirm or err on leave channel
• Check with Explorer team which errors to notify
• Reset channel notification settings

• Implementation in friends saga
• It should be paginated
• Message from renderer to kernel with # page, # results, type (CHANNEL or FRIEND/PRIVATE)
• Result of get joined from kernel to renderer

With the new Pick Realm Algorithm, close peers should take priority when picking a realm.

The algorithm has this feature, but it is being ignored quite often because of the definitive decision threshold.

The threshold is OK. But the issue is that we are not filtering those candidates that have close peers when passing the context to the next link. We should change the "picked" part of each link, to ensure that even if no definitive decision was made, the first links take priority over the others.

jeremiah@DESKTOP-D1U2IB0:/mnt/e/Andverse/kernel$ make watch
node_modules/@types/express/index.d.ts:58:29 - error TS2694: Namespace 'serveStatic' has no exported member 'RequestHandlerConstructor'.

58     var static: serveStatic.RequestHandlerConstructor<Response>;
                               ~~~~~~~~~~~~~~~~~~~~~~~~~

scripts/runTestServer.ts:247:49 - error TS2345: Argument of type 'string | string[] | ParsedQs | ParsedQs[]' is not assignable to parameter of type 'string'.
  Type 'string[]' is not assignable to type 'string'.

247     const resultPath = path.resolve(resultsDir, req.query.path)
                                                    ~~~~~~~~~~~~~~

scripts/runTestServer.ts:248:50 - error TS2345: Argument of type 'string | string[] | ParsedQs | ParsedQs[]' is not assignable to parameter of type 'string'.

248     const outputDiffFile = path.resolve(diffDir, req.query.path)
                                                     ~~~~~~~~~~~~~~


Found 3 errors.

make: *** [Makefile:27: scripts/npmPublish.js] Error 1

how to solve?

New comms connection

Objectives

• Consistent new realm selection algorithm
• The development must support:
  1. Support legacy "realm-name based comms"
  2. Support new comms methods and protocols
  3. Support current "v1-local" comms for CLI

New selection algorithm

// selectRealm function may be called at different moments
// - Load of the app, to connect with the provided realm in URLSearchParams
// - When the current realm goes offline and the explorer needs to find a new candidate
fn selectRealm() {
    // 1. checks query string &realm=artemis
    if (qs.realm && let realm = checkRealmConnection(qs.realm)) {
        return changeRealm(realm)
    }

    // preview mode should end here
    if (PREVIEW)
        return changeRealm(PREVIEW_COMMS_CONNECITON)

    // 2. find next realm based on candidates
    {
        // 2.0 look for candidates
        let candidates = fetchNewCandidates() || cachedCandidates()
        // 2.1 cache candidates for next time
        saveCachedCandidates(candidates)
        // 2.2 find suitable candidate using predefined algorithms
        for (let realm : candidates) {
            if (checkRealmConnection(realm))
                return changeRealm(realm)
        }
    }
}


// changeRealm function is used to effectively select the new realm to connect
// It is used by SDK & `/changerealm <name>`
// It fails if the connection *may be* unsuccessful (decided by checkRealmConnection)
fn changeRealm(connectionString: str) -> Err | Ok<()> {
    let resolvedRealm = checkRealmConnection(connectionString)

    if (resolvedRealm is Err)
        return Err(resolvedRealm)

    dispatch(setNewRealm(resolvedRealm))

    return Ok()
}


// Function to check whether or not we can connect to a realm
// 1. Protocol is valid
// 2. Server is reachable
fn checkRealmConnection(connectionString: str) -> Err | Ok<Realm> {
    let resolvedRealm = resolveConnectionString(connectionString)

    if (!protocolSupported(resolvedRealm))
        return Err("Comms protocol not supported")

    if (!ping(resolvedRealm))
        return Err("Cannot contact server")

    // check for amount of users or credentials (private matchmaking)
    if (!acceptsMyConnection(resolvedRealm))
        return Err("Access to server denied")

    Ok(resolvedRealm)
}

Considerations for every new comms methods:

Room-based protocol that supports different message types

Current room-based messages messages are:

• Profile (broadcast)
• Profile Request
• Profile Response
• Voice message
• Position message
• MessageBusMessage (scenes)

Current lighthouse messages are

• Topics based messages (Heartbeat)
• Islands management

Problem:

The kernel is currently destructuring the response from the builder-server as if it was the same object that is store in the catalyst but there are a few differences when it comes to Emotes.

Tech details:
When trying to access the emoteDataV0, it always get undefined so the Emote data is not loaded correctly.
const { id, data, rarity, i18n, thumbnail, description, emoteDataV0 } = v2Wearable
The builder-ser ver replies with an Item instance, that will have a type prop. Let's use the type prop to detect when it's an emote and read the emoteDataV0 from the right place.

Profiles is one of the most frequent request that explorer makes while a person is using it.

Of the most frequent ones, is the one that we are not caching. This is because there is a particular common use case that'd be broken by caching:

1. I meet with my friends in world, to show them this cool wearable that I've got
2. I equip this wearable
3. My profile gets updated. I announce the update through comms.
4. My friends request the profile to the server. If we have caching, they could get an old version
5. They don't see I changed my wearable. Everybody is confused and unhappy :(

But there are ways to have caching and also support this use case: When a peer announces the profile modification through comms, it sends a "version", which is an incremental number. We can add that version to the query string of the request sent to the server, in order to change the URL. If the URL has changed, then it won't be cached by HTTP servers.

For instance: https://peer.decentraland.org/lambdas/profiles?id=0xA6CaB202588Bbd84bC3336C6B13Bb0542Bf0A6A7&version=15

This would be the first step. Once this has been implemented, we can change cache directives for the profiles endpoint without worrying about breaking this use case.

• ⚠ Review the feasibility of this without actually having to retrieve all messages for all friends
• Renderer->kernel message to load friends with existing conversations (at least one message) (paginated)
• Kernel->renderer message with friends with existing conversations (paginated)
• Implementation in friends saga

Description

After doing several tests with several people, we have reached the conclusion that something in Kernel side broke the Voice Chat in some point and it is not related to .zone or .org as we though at the beginning. We have found some cases (like @olavra) where this Voice Chat issue is happening ALWAYS:

1. He try to activate the microphone clicking the microphone button.
2. The browser ask about the needed mic permissions and he allows them.
3. From this point on, the microphone button keeps indefinitely pressed but he never receives any update from Kernel. All the voice chat system seems to be totally deactivated and he can't send audio neither receive it from anyone.

However for other users (like @sandrade-dcl) the Voice Chat is working perfectly... it is very weird.

We have also checked it doesn't mind if the test is done from Mac or from Windows, if it is .org or .zone... we have gotten different results depending the user.

Acceptance criteria

• The Voice Chat system should work fine for all users.

• Add data to init message in RFC

When connecting the Unity Editor with current Kernel version, the rendering never enables if we connect to ZONE or to a local kernel server for test scenes (DEBUG_MODE), thus blocking any debugging from Unity Editor connecting to those 2 environments.

For example, this is the CORS error that appears when trying to connect to ZONE with the following url https://play.decentraland.zone/?ENABLE_AVATAR_LODS&LOS=0&position=92%2C151&realm=baldr-amber&ws=ws%3A%2F%2Flocalhost%3A4999%2Fdcl&NETWORK=ropsten

And this is the CORS error when trying to connect to a local kernel with the following url http://localhost:3000/?DEBUG_MODE&ENABLE_AVATAR_LODS&LOS=0&position=92%2C151&realm=baldr-amber&ws=ws%3A%2F%2Flocalhost%3A4999%2Fdcl&NETWORK=ropsten

Full log in case it helps...

1. Go to the three dots, pick night mode
2. Reload
3. Night mode is not there, expecting it to work as per the previous session

This is currently happening when starting up the client and many concurrent calls to the account_data PUT endpoint are made. The main flow keeps running towards friend messages fetching when this ends up erring.

localhost:kernel c$ make watch
decentraland-compiler version: 3.1.9
decentraland-compiler version: 3.1.9
decentraland-compiler version: 3.1.9
decentraland-compiler version: 3.1.9
decentraland-compiler version: 3.1.9
make: *** No rule to make target static/voice-chat-codec/audioWorkletProcessors.js', needed by build-essentials'. Stop.

Sometimes the "Another session was detected" error appears with no reason, completely breaking the experience, It happened to me 2 or 3 times at random moments. I am 100% sure I didn't have any other session open.

Last time was while playing the Salmonomicon after walking all the way there from Genesis Plaza.