add SearXR to apps.md

[coderofsalvation]

demo/usage:
https://blog.searxr.me/30%20code/remotestorage.html
https://id.420129.xyz/watch?v=R3IW945yhU4

[DougReeder]

I'm very intrigued, as I'm enthusiastic about both WebXR and remoteStorage, but it's not clear what your app does or how it works. I entered the URL of a .glb file, and it took me to the root page of the website. When you mention XR, it's not clear if the app is an XR app, or it's searching for XR experiences. The video is helpful, but not everyone will sit still for that long, and it only addressed the remoteStorage aspect.

If you could add some documentation to orient users, that would help ensure users actually get something out of your app, and I'd feel better about including it in the list.

[DougReeder]

Separately, I'm curious if you're looking for web pages with VirtualLocation metadata (https://schema.org/VirtualLocation).

[coderofsalvation]

Thanks for trying.
Like the footer says, its a SearX-instance, a searchengine.
So if you search 'hand' e.g., it will give results (there's not more to it)
Documenting such standard usecase (a search-textfield) is not needed imho.
Worstcase you can click the searx-link in the footer, to read about the (awesome) SearX project.

Perhaps you're talking only about the glb URL-viewer-usecase?
This is an experimental usecase of XR Fragments.

but for the sake of this PR keep in mind that the app is 'just' a searchengine, like the footer says

about entering GLB urls:

• try entering https://xrfragment.org/index.glb to get an idea
• you might have triggered a bug (I don't know, afaik .glb URLS are the safest bet)
• the XR Fragment-parser will be refactored starting from june (as THREE.js had some breaking changes)
• garbage in/garbage out: expect strange things when loading a random 3D model which is not position at location 0,0,0

Unfortunately I don't have more resources to tailor/explain things beyond this PR.
So I was hoping that this FOSS app + repo would be interesting to include as-is.
If this is not turnkey-solution-ready enough to include, then I'll accept that too.
(but again, I would like to adress that it's a searchengine)

VirtualLocation

Thanks for pointing this out, I think I've seen this before.
Perhaps this is more something for online conference/zoom-meetings..something mobilizon would use perhaps?
Most of its fields are already covered by the aria- + og: + dc: metadata of XR Fragments so 3D models which are XR Fragment-compatible won't benefit much from it.
Anyways, in case you're interested: IF websites would repurpose this schema for AR/VR locations, one could setup a separate FOSS scraper-searchengine (like yaci) in order for SearX (a metasearch-engine) to source from it.

[raucao]

It would be really good to use the correct content type when storing JSON objects in a remote storage. This is automatically done when you use the storeObject() function in rs.js, or you can add it via function argument when using storeFile() (but you won't get object validation for free).

For example, in Inspektor, you can view and edit JSON documents in a special tree view/editor. But also, any other apps should also be able to detect that it's JSON content.

As a general recommendation, it's always a good idea to store things like the favorites in separate documents, because that's making it very safe to sync data without running into conflicts, when an app is used on more than one device, or data is accessed by more than one app.

rs.js makes that easy, too, e.g. if you store all of them in a /searxr/favorites/ folder, you can just use rsClient.getAll('searxr/favorites/') to load all of the objects at once.

[coderofsalvation]

good points.
The current json-file has a version-field, so your theoretical refactor/migration could be painless and silent for users with the old file.
(Unfortunately as stated before, I cannot tailor things beyond submitting a community URL here)

TBH: this PR is just a markdown file with an extra link of RS-usage, because I think it will help grow RS.
This is my second PR, but imho these PR reviews go way to far into the weeds.
Submitting a community link should not trigger such audits imho (this is not a flagship app maintained by remotestorage org).
For community-efforts, deep audits do not make sense resource-wise nor adoption-wise.
My suggestion is to be more liberal in promoting community/adoption efforts when it comes to community URLs.
I do however, understand stability/best-practices-concerns, so perhaps an idea is:

• to express stability/quality in an extra column in the apps.md (badge or stability with value beta e.g.)
• ask the developer of the PR to include it (value decided by you)

another take: just create an in the wild category for community adoption without deep audits.

[raucao]

I think the terms "deep" and "audit" are not accurate here. I simply tried out the most basic function of the app and looked at the stored data.

The first thing I saw was an actual mistake in the listing, which I provided a correction for, that takes one click to commit.

Then, when I saw that the app is using the protocol wrong on a very basic level (content types are a corner stone of sharing data between any apps), I added this to my PR review, including pointers for solutions, and without requiring changes to be made.

I also immediately ran into the sync not working correctly (it failed to remove all the bookmarks when I quickly deleted everything I hadn't explicitly stored myself), upon which I provided a recommendation for a best practice that avoids this entire class of bugs.

I can see that it's frustrating to submit a link, only for people to find various issues with your new app. However, if the first two users trying out the app immediately have issues when using it, then don't you think other users coming from the Apps page will also have issues? Also, you're getting free testing and reviews from experienced devs here, which is honestly something I'm personally incredibly grateful for when I publish my own code on the Web.

As stated before, the basic requirement for an app to be listed is merely that it's clear for a user how they can store and access data, and that it's not outright broken. Everything else is just free help to improve users' experiences, as well as interop in the ecosystem.

[coderofsalvation]

I politely disagree with the premise that I was asking for an 'free' sourcecode-review/consult.
I'm just adding a line to markdown file in this PR.
Anyways, if it helps to get this PR approved: I've updated the content-type and made sure deleting items are reflected in the json.

Final thoughts: many thoughts and questions are reasonable in this PR-review, but kind request to use this issuetracker instead from here on.

For a PR of this repo, I (and probably more future RS-adopters) come from this angle:

• I'm supergrateful being able to allocate time for RS,
• Time is limited, must be used smart
• Projects mature in iterations (avoid premature optimisation at all cost)
• When time is up, I share/PR links where-ever I can to boost visibility of cool open standards
• FOSS should not by default be held against MVP/turnkey-solution expectations (instead YOU can fork/tweak/selfhost)

The last 2 points seem to go against this (and previous) PR process.
With the last PR I thought the 'free/deep review' was incidental..but no.
I expect PR-workflows for URLs to be like awesome-repositories like 0data.

Perhaps an awesome-remotestorage repository might be worth creating at github.com/remotestorage/awesome-remotestorage like 0data.
These are unofficial listings with a 'the more the merrier' PR-policy (what I incorrectly assumed to find here too).