HTTP API Requests

SDK Feature Requests
,
1

Hey!

I just started developing in the Playdate SDK. I Find it very cool so far, but the only feature I am disappointed at not having is HTTP requests.
I am planning on making a weather app and a social media client. I know that you can use playdate.simulator.getURL(url) in the simulator, but I would like more functionality.
Here are some example of requests:

  • playdate.requests.get("https://api.wasteof.money/session", json = {"username": username, "password": password})
  • playdate.requests.post("https://api.wasteof.money/posts", headers = {"token": token, "content": content})
  • And other types of requests, such as PUT, DELETE, PATCH, etc.
6 Likes
2

It's definitely something we'd like to do, but we need to figure out the best way to do it while balancing performance, security, battery life, and other concerns. Wish I had a better answer!

7 Likes
3

When could we expect this to be released?

4

add curl support first in C. I am sure it is the best way to start

1 Like
5

I'd be interested in being able to make HTTP requests as well.

In the absence of that... is there ANY networking functionality in Playdate SDK that I can get to? Like, can I create and connect a TCP socket (ok, some TLS would be great also; ) in C or Lua (or Rust?; )?

1 Like
6

In the simulator, there is playdate.simulator.getURL(url)
It doesn't exist on device, but that's the closest thing there is at the moment.

1 Like
7

Have you considered implementing a gopher protocol client instead of HTTP requests? Since gopher is far more limited it eliminates a lot of security concerns. Plus it fits in with the Playdate's quirky nature in my opinion. Even one of Panic's founders embraces the gopher protocol!

gopher://stevenf.com/0/journal/2022/02/28/playdate-sdk.txt
gopher://stevenf.com/0/journal/2022/04/18/first-playdates-shipping.txt
3 Likes
8

why would something exist in the simulator but not on the device? That's insane.

No http capability severely limits what I want to build. I thought I finally had a niche place to build LLM or GPT capabilities into a game...

9

security concerns. for example, a game could record you and upload it to a remote server without your consent or knowledge. they're also trying to balance out battery life issues with it, but it's been over a year since I asked so I have no idea where they are on working on it.

10

For me at least, it would be totally fine to have local network access (or maybe a HTTP server) for my own in-dev stuff. It certainly would be fun to build a game that uses a database of parameters I could live reload over the network as I'm developing it.

11

It's already possible to live reload during development, though obviously not over wi-fi.

you might enjoy the approach.

https://devforum.play.date/t/splitting-a-game-into-several-functional-binaries-nics-plugin-manager/1387/5

12

In my opinion, the biggest potential problem with allowing network access would be the appearance of ad supported games

The lack of advertisements in games on the PlayDate is a huge plus to me about the platform

5 Likes
13

+1 on limited HTTP access. Honestly, my wishlist for the playdate would have been "shoulder" buttons (for rotations / tabbing when making puzzle/mystery games) and very limited WiFi access for puzzle downloads and making utility/knowledgebase style apps. I think Vivi's request for a synched KV store I can manage from elsewhere without fully recompiling + reuploading the app is exactly one I share, just not only for development, and is all I think most people in this thread are after if I'm reading right.

For the latter I think most security concerns could be alleviated with narrow verb, rate limiting, payload size and type, and protocol support (GET/POST and 10KB table[str, str] only, for example), either a manifest file whitelisting a single URL (others can be inferred via a protocol, below) or a Panic-hosted service, and a user notice at app launch and at network request (similar to content warnings currently) - so effectively anything more than simple database access is at the very least highly impractical.

I don't share many of the concerns in this thread:

  • Whilst these preventions (short of panic hosting) won't stop e.g. ads/spam/datahoarding via sideloading, Panic can set policies on Catalog (or the hosted service) to prevent ads via that "preferred" channel.
  • Shovelware already exists on itch, so I don't think adware wouldn't be a distinct issue.
  • Power draw / poor performance wouldn't be a factor worse than UX if there's a system popup each time, allowing the user to opt out of a poor experience.
  • There's not going to be much information in PDX containment for privacy to be a massive concern :smiley:

tldr; wishlist

  • Panic-hosted KV store (similar to Scoreboards) for general access (with reasonable limitations and a system popup to prevent spamming);
  • Or minimal support for online KV sync, e.g.
    • GET {pdxinfo.KV_HOST_URL}/{key_prefix}/_
      Accept: x-www-form-urlencoded
      Purpose: to allow namespacing via dot notation or other, e.g. in the form 'puzzles.{creator_id}.{puzzle_id}' or 'preferences.{device_id}.{preference_id}'
    • GET {pdxinfo.KV_HOST_URL}/{key}
      Accept: x-www-form-urlencoded (content length < 256)
      (I actually think this may be a bad idea for caching / request spam)
    • POST {pdxinfo.KV_HOST_URL}/
      Content-Type: x-www-form-urlencoded
      Content-Length: <256
  • SDK helpers for above, and a device identifier for use in keys:
    pd.networking.kv.get_from_prefix(prefix: str): table[key: str, value: str] raises
    pd.networking.kv.get(key: str): str raises
    pd.networking.kv.set(values: table[key: str, value: str]): void raises
    pd.networking.deviceId(): str
1 Like