Make APP compatible to macless-haystack

[miha-perfecto]

I have a service that works with the web version of macless-haystack project https://github.com/dchristl/macless-haystack - it would be convenient if the application also worked with it and did not require entering Apple account data

[parawanderer]

I thought of this already and I think this would be a cool change, but relatively significant UI and internal data formats/glue wise. Though the main problem is that I don't have any test setup for this and am a bit busy to try and get one set up from scratch these days.

I'm not sure exactly what the difference between dependencies/data requirements for legitimate apple tags versus arbitrary custom tags are. Maybe @malmeloo could give a quick overview of that.

But yeah definitely something I think it would be cool to have in the app, just likely not something I'll have time to look into personally right now

[parawanderer]

Also, can we query legitimate apple tags without the apple login? 🤔 Because if we can do that then I think both my app but specifically @malmeloo's library should just use that solution.

Deleting the full UI for the login stuff would be easier than adding variants to it on my end.

In fact I think that would imply dropping the anisette dependency in it's entirety?

[malmeloo]

Querying custom tags is relatively easy, instead of passing a FindMyAccessory object to fetch_reports, you just pass a KeyPair. The only difference between these two is that official accessories use a key generator, whereas custom tags usually just use a static key. IIRC, macless-haystack uses a proxy server that simply forwards encrypted location reports. Depending on how much the proxy alters the report, technically speaking you can simply create a new LocationReport and call its decrypt method with the correct KeyPair. You would then have access to the full report object without having to make any API calls to Apple's API (so no Anisette requirement, either).

You cannot query location reports (whether from a legitimate or custom tag) without logging into an Apple account, because the endpoint is authenticated. However, if you use the macless-haystack proxy you could technically drop sign-in in its entirety, since you'd be using the proxy's session instead.

[miha-perfecto]

Also, can we query legitimate apple tags without the apple login? 🤔 Because if we can do that then I think both my app but specifically @malmeloo's library should just use that solution.

it's simple - apple login/password/2fa data is required once inside the macless-haysteck container, and then the token is stored in it

Deleting the full UI for the login stuff would be easier than adding variants to it on my end.

In fact I think that would imply dropping the anisette dependency in it's entirety?

No, because macless-haystack works in tandem with anisette

P.S. maybe it's more secure in a self-hosted solution if I am not mistaken

[parawanderer]

it's simple - apple login/password/2fa data is required once inside the macless-haysteck container, and then the token is stored in it

@miha-perfecto Oh, hmm, well, isn't that equivalent to the current setup in this app then from that part? That's basically what this app does too. 🤔

And, thanks @malmeloo!
Then, for the "just making it compatible with the unofficial ones" part, it sounds like it wouldn't be outrageously difficult then fortunately -- but still this would take non-trivial code changes that would take a good chunk of time.
Mostly glued on top of what the app already does for the regular tags. Probably mostly polymorphism glue, as there's logic surrounding tag displaying that references official metadata like names etc that I imagine won't map 1-to-1 to a plain keypair setup.

[miha-perfecto]

OpenTagViewer_macless_haystack_INTEGRATION_GUIDE.md

chatgpt analyzed both repositories and claims that it is not difficult :)

[parawanderer]

Well... I mean it's still code changes that somebody needs to do & make time for, right?

If you can get ChatGPT or some other tool to do it all outright, I'm more than happy to review a MR. But doing it myself requires making time for it in my schedule -- which is currently a bit difficult. The changes themselves aren't difficult per-se, just time-consuming to do/validate.

In fact, if you figure out a way to just get it to implement these types of changes outright then there's one more task on the backlog for this project that I would be curious to automate: integrating alternative map providers with the ability to choose a different one. Another thing that can't really be classed as "difficult", but another large glue change.

[miha-perfecto]

Ok, i understand you!
You can leave this idea here, maybe someone will have more time or I will get around to it too.
:)