I see we already have syncData.parent here, so adding a new field to sync a parent id seems redundant. I think it would be better to modify getParentId and initNetworkParent here, and keep the addEntityToPage(entity, parentId) signature.

Instead of modifying the basic example. Can you create a new example where you absolutely need your changes.
For this modified example, instead of attachToParentId:#platform;" you can really just use position="0 10 0" on rig and it will be absolutely the same.

Yeah sure, did you have an idea of what example would be good? Perhaps I can change it so the client can manually set the hight of the platform local to his own computer. Then I think you would absolutely need this change. Does that work?

I'm asking you because I don't know which use case those changes would really be useful. If I merge changes, I want an example where the changes are necessary and the example can't be achieved in another way.
Having the height of the platform configurable doesn't change anything, you change both position y on rig and platform and that would do it without the changes.
Didn't you have a real use case for those changes?
Your modified example seems the wrong use case to me. What about a second platform, where the avatars can go, you will need to change the parent of your avatar, how would it work? Generally you would not put your avatar rig as a parent of another entity but use a root entity, you would then update the avatar rig according to where the avatar is. This is how it works with the two different navmesh components we have.

Apologies in advance if I misunderstood anything.., here is why I think my example works.

Example: Player A's platform's y=10, Player B's platform is at y=20.

On Player B's local client, how would you ensure that Player A ends up on my platform? If you set Player A rig entity position to y=20, then the next time Player A moves, the rig's position would get updated back to the original y height since its rig is networked entity right? If it is still unclear I can make the example and perhaps you can try it.

(side note): I tried setting the position of a networked entity (from another client) and it did not update, maybe there is logic that prevents this anyways?

Real Life Example

Here is a video of a real use case, I can attach the scene code if it helps, but in summary, each client has a sort of "platform" whose position is local the client. In the video the "platform" is the green outline, which is tracked and changed locally on the client. A different phone viewing the same target can have a different position for the "platform".

The thing I care about syncing is the robot's positions, but only relative to the "platform". You can think of the "platform" as the root of my networked scene.

  <a-scene>
    <a-entity id="platform"> //local client can set this to anything. The position here only makes sense to the client so it should not be networked.
      <a-entity id="avatar" networked=""template:#avatar-template> // The robot's position in the scene should make sense relative to other players in the scene as well. 
      </a-entity>
    </a-entity>
  </a-scene>

For your side note, you need to call NAF.utils.takeOwnership(yourEntity) to be the owner of it so the changes propagate to the other users.
Ok if you have a different platform height for each user, your example indeed is fine, and of course you don't want it networked.
What I wanted to understand is why you need a platform height different for each user.
From your video I really don't know what I'm seeing.
But I can see that it can probably be useful if you set the platform height corresponding to an anchor on a table in AR for example, although you could just set the position on a-scene I think.
It would be interesting to have an example with one user on desktop and another with Chrome Android with AR on the phone moving a character like your video.

Great, so just to confirm, I will plan to make the example with platforms of different heights then if that's okay with you?

You can play around with it after and try out your suggestions if you still have any doubts 😄 .

Yes please go ahead.
I don't know if you have an ARCore compatible Android phone. If you do, you can look at creating an experience in AR to place the platform on a table, see https://github.com/AdaRoseCannon/aframe-xr-boilerplate for an example. Chrome Android is only implementing hittest, that's enough to have the correct height of the table. Out of scope here, but I think you can now detect a plane on Meta browser on Quest, so probably you can know the table boundaries and set the width and height of the platform accordingly too.

Should be "non-networked-parent.html"

Should be "entities as children"

I like that we've added this documentation as comments. I would recommend also adding additional information visible in the UI of this example explaining what this example is and how to use it without needing to inspect the source code. See the "Persistent spheres" example which includes the header at the top as an example.

I would recommend setting line 135 to just var nonNetworkedParent; and then the assignment for nonNetworkedParent could instead happen on this line as:

else if ((nonNetworkedParent = document.querySelector(#${parentId})))

That way we can avoid running the querySelector call if we enter the first if condition.