The random UI change(s) is something we have to detect really quickly & fix - or maybe in the future use AI models to read the data (if there was a way to ascertain that there's be no hallucinations).
Per the ToS and scraping, the way the SDK is built is akin to if we had a browser like Brave, Gener8 or even Chrome itself. These browsers essentially already "scrape" what the user is doing.
We think end-users should & will always have the right to always decide how they'll browse the web and can share whatever they choose to.
It's also similar to installing a chrome extension that does the "scraping" for you - just with a much smoother UX, we think the end-user should always have a right to decide to do stuff like this.
Lastly, we stay clear of any intellectual property, the only data we collect on behalf of the user is data on activity that they generate - so for example, Gandalf can tell the title of the show a user watched on Netflix, but we do not scrape images, video content, anything that's Netflix's IP.
It's a little similar to how Plaid worked but different in that authentication into the services happens on the user's device.
This is in contrast to the other kind of scraping where the end-user has to trust Plaid (or whoever) with their passwords, Gandalf triggers an App Clip with a WebView that lets the user authenticate (in the same way they'd do on their browser) without compromising creds, then scraping happens.
Client Manager is a mountable Rails (engine) gem that helps identify and authenticate your API clients.
Motivation:
To understand why this gem exists, let's look at a simple example of a blog application built with a Rails API and any JavaScript front-end framework. In the API, you're probably going to have some endpoints that only logged in Users/Authors can access. Like creating or deleting a blog post. Other endpoints, however, like reading posts, will be unauthenticated. This means that if one should go to the read endpoint using a browser, the whole JSON response will be displayed. What would be ideal, would be make it such that only the front-end application can access the read endpoint(s).
Typically to do this, you might generate a random UUID and ask the front-end developer to put it in the header of their requests. But this doesn't scale well. What if you want to add an Android app? Or an iOS one too? That's where Client Manager comes in. It helps you easily manage all of this with a simple User Interface. With Client Manager, you can:
Create clients with an automatically generated JSON Web Token, which can be used to authenticate requests
Create users with the ability to create (a specified number of) clients themselves
Per the ToS and scraping, the way the SDK is built is akin to if we had a browser like Brave, Gener8 or even Chrome itself. These browsers essentially already "scrape" what the user is doing.
We think end-users should & will always have the right to always decide how they'll browse the web and can share whatever they choose to.
It's also similar to installing a chrome extension that does the "scraping" for you - just with a much smoother UX, we think the end-user should always have a right to decide to do stuff like this.
Lastly, we stay clear of any intellectual property, the only data we collect on behalf of the user is data on activity that they generate - so for example, Gandalf can tell the title of the show a user watched on Netflix, but we do not scrape images, video content, anything that's Netflix's IP.