Publishing Apps

Publishing Apps

As you may or may not know, we have a widget library and CLI tool named Pixlet to author and develop apps for Tidbyt. In addition, we have an API where you can push images and configure your device programatically. What we don’t have currently is a way to publish apps to Tidbyt.

Background

The way our backend works is we load up starlark files using the same rendering library available in Pixlet. Every time an app needs updated, we execute the starlark on our servers and send the result back to the appropriate device. This means if we want to support publishing thrid-party apps, we need to be able to run them in an isolated and secure fashion that doesn’t open our platform up to being abused. The good news is, this isn’t impossible. The bad news is, it’s going to take some time to get right.

Current Workaround

We loved Max Timkovich’s Fuzzy Clock and we got their permission to include it on our platform with attribution. This approach could be done again in the short term - reply to this discussion if you want to see your app on our platform and we’ll see if it’s something we can support. A few things we still need to square:

  • Software licensing: we need to make sure we’re able to use your software without violating any laws. MIT licensed code makes this really easy.
  • Config values: we configure apps through a structure in our mobile app that we haven’t open sourced just yet. If your app requires a lot of config from the user, it will be pretty hard to support in the short term.
  • Bug fixes or updates: for Fuzzy Clock, we simply vendored the code in our repo. This means we’re not getting any updates and it makes it hard for us to push fixes in reverse.
  • App name and copy: we need to know what the app name, summary, and description should be and who to make attribution to.
  • The future: if we do this, how do we migrate to the new workflow in the futre? :sweat_smile:

Potential Workaround

One idea we had was to create a Community Apps repo where folks can make a pull request against. That way, we can review the code running on our servers and pull the source from the main branch as part of our release process. We could also have a license in the repo and potentially an agreement as part of the PR process. Would love to hear your thoughts. Is this a workflow that you would like to use?

Feedback Wanted

Have ideas we haven’t thought of? We would love to hear them. Let us know in the discussion below.

6 Likes

cc @kay - would love to hear your thoughts here :smiley:

The Community Apps repo seems like the sensible, more scalable way to do things. It would allow bugfixes, and attribution is inbuilt.

In the mean time, I’d be delighted to see my apps on the platform. The Pac Man one is certainly a legal nightmare, don’t use that :slight_smile: I can change it to something less trademark-infringy.

4 Likes

Would such a system be able to fetch images for display or would it only work with Pixlet?

Is my understanding correct that if we are running/serving the apps ourselves, we lose access to the default apps (stocks, weather, etc)? Due to not having those .star files to execute.

Yes! By creating a Community Apps repo, we could run your script like we do for all of our internal apps. So you’d be able to do all sorts of HTTP operations inside of your app

1 Like

If you use the Push API you can set an installationID. If you do, the device will show installations in order and use your latest pushed images for that ID.

If you don’t set the installationID and simply push images in a loop, it will take over the device and no longer display your other installations until you stop pushing.

Let me know if that makes sense :smiley:

Thanks for the reply, Mark!
I must not understand the Push API like I originally thought. The device behavior is identical for when I set a unique installationId (along with the Base64 image property) and when I leave installationId off entirely. The pushed image immediately takes over the device for X number of seconds in both situations.
There doesn’t seem to be an order that is respected with the pushed image.

Also, the newly added installation doesn’t show up when getting the list of device installations via API.
I must be missing something?

1 Like

Well derp. Upon further investigation, I was not capitalizing the “D” in installationID, which was causing a silent issue registering the app. With the fix, everything seems to be working as expected :slight_smile:

Hello,

I just received my Tidbyt and am really enjoying tinkering around with it. I’ve created a Twitter app that can show your follower count, or the follower count of any username you’d like.

It looks like this:
twitter

You can find it here:

I think it would be cool if this could be published for others to use.

Thanks,
Nick

4 Likes

When I push with an installationID, it replaces the current image with the pushed image. Similar to what @theblake was saying

The pushed image immediately takes over the device for X number of seconds in both situations.
There doesn’t seem to be an order that is respected with the pushed image.

Is there a way to update an app without replacing what is being displayed?

Hey @mark, I’m consistently getting this error when trying to use the Push API with curl:

{"code":16,"message":"auth error: rpc error: code = Unauthenticated desc = Bad authorization string","details":[]}%

I’m using the same API key and Device ID that I’m using for Pixlet (which is working fine to push webp files to the tidbyt).

@Millsionaire, what does your curl request look like?

If I’m reading this right, this means that I could push an image continually to the same installationID and it would remain in the rotation and display the new image each time through the rotation?

It would be fantastic if there was a way to manage a link between an installationID (potentially providing it to an app as an app key) so that a 3rd party app could link a deviceID through authenticating with a tidbyt account. Once that’s done, the app could use its assigned installationID and deviceID to use the push API to update a given user’s app “state” using the push API. At that point, that feels like a way for developers to run their own infra while only dealing with images and the Push API without running arbitrary code within tidbyt infra

As an app developer the next potential api extension I think I would want is a way to say “use this next push as a notification” to pull it to the active app before returning to the rotation. The use case in mind is that I have is a “live now” type notification (I’m thinking of a " went live type app that I’d want to display briefly immediately. Another usecase for this would be a “new donation/follower/subscriber” style notification)

The one thing that immediately comes to mind that would need to be solve with this type of model is rate limiting to not DDOS your API

@tget4 This is what my curl request looks like:

curl --request GET \
  --url https://api.tidbyt.com/v0/devices/<DEVICE ID>/installations \
  --header 'Authorization: <API KEY>' \
  --header 'Content-Type: application/json'

@Millsionaire make sure you are adding Bearer to the Authorization header

Authorization: Bearer <API-KEY>

3 Likes

That was it. Thank you!

1 Like

I love your community repo idea. I’m a developer at a company that does something similar – we have a community repo that anyone can make PRs against to update their own code or even someone else’s, and our paid developers review it before pushing it into the wild. But in our case, even if you wrote the code, because of the nature of the product it’s kind of “community property”, and I don’t think that’s the case here. It would have to be a little stricter on who can update what. I wouldn’t want strangers deciding that they don’t like the size of the image on my app and just making a PR on it with no permission from me, you know?

Anyway I made this little app that pulls a random reddit post from a list of subreddits that a user would define on their phone, gets a random image post from the list of hot posts, and displays it with the title, subreddit, and ID.

It would be cool if this was an app, because the way things are pushed right now, I would have to run a script constantly on my macbook to update the actual post it’s displaying and my Macbook isn’t my main machine so it’s not on most of the time and none of this works on my Windows machine at all. :frowning: It uses the public Reddit API, so there’s no concerns about permissions, and the only user configuration it needs is a list of subreddits to pull from.

I just want to give you guys my code so I can get that sweet sweet dopamine of cats in ties popping up on my device. Thank you for your cat-tie consideration.

2 Likes

@dmc I think I’d prefer the inverse of this. I’d like a webhook app where I can configure an endpoint to make an HTTP request every time the app is ready to display (with DeviceID/InstallationID in the payload). This endpoint would live on my own infrastructure and would be responsible for returning a webp/gif/jpg. Then there’s no worry about Tidbyt managing my code or worrying about DDOSing their APi

The great thing is both ideas aren’t mutually exclusive, so both could be supported, giving developers flexibility of the model they’d like to support

The reason I suggested the “developer push” model is that the current API is fairly close to supporting it. You could do “developer push” with the webhook version as well: if Tidbyt offers the option of triggering a pull, then you can use Tidbyt for time-sensitive updates.

I’m interested in the breaking news, someone just went live, real time notification possibilities of Tidbyt and would be disappointed if there’s no possibility to say “I want to show this up now” type notification (as I type this, there is a feature request in the suggested topics for PagerDuty notifications, which would likely require this type of usecase)