Live Value Updates

[thebells1111]

Here's a link to a repo that has a functional socket.io server and delivers the expected payload to a client.

https://github.com/thebells1111/live-updates

For now, I have the live socket.io server url in the pocast:liveItem tag as an attribute called liveValueLink, but that will probably change as we flesh this out. However, for the time being, create a socket.io connection on the clinet side that connects with the server found in liveValueLink, then listen for a message from the server called remoteValue. The expected payload will look like this for anyone wanting to listen to a live session and display the contents in their own app. None of my apps are currently broadcasting lines 3 and 4, but I have them there for anticipation of polls.

{
  "title": "This is the title for this block.",
  "image": "https://cdn.masto.host/podcastindexsocial/accounts/avatars/000/015/466/original/1dcbcde7619f90a7.png",
  "line": [
    "this is line 1",
    "this is line 2",
    "this is line 3",
    "this is line 4"
  ],
  "link": {
    "text": "This is the text for the link",
    "url": "https://podcastindex.social"
  },
  "description": "this would be an area for something like show notes",
  "value": {
    "type": "lightning",
    "method": "keysend",
    "destinations": [
       { "name": "The Split Kit",
        "address": "030a58b8653d32b99200a2334cfe913e51dc7d155aa0116c176657a4f1722677a3",
        "customKey": "696969",
        "customValue": "boPNspwDdt7axih5DfKs",
        "split": "5",
        "fee": "false"
      }
    ]
  },
  "type": "person",
  "feedGuid:" ("optional guid to feed if it exists,  i.e. pulling info from an existing podcast/album")
  "itemGuid:" ("optional guid to item if it exists, i.e. pulling info from an existing episode/song")
}

[thebells1111]

A new tag should be introduced into the namespace to make this extendable. I'm proposing

<podcast:liveValue uri="link to server" protocol="protocol use" />

I'm not aware of all the possible protocols and what other attributes they would need in the tag, but the ones I'm aware of are 'socket.io', 'websocket', and 'xmpp'.

For the time being, I'm only supporting 'socket.io' as it's the one I'm most familiar with for developing.

[mitchdowney]

@thebells1111 so @kreonjr and I have begun looking into adding liveValueLink and remoteValue, and so far the proposal makes sense, but there are 2 problems in particular that I am not sure how we address, and I think we may need to consider when defining the final spec:

1. When a listener plays a livestream that is already in the middle of a "live value update" section, how does the app receive that information? Can the app receive the remoteValue event on connect? If no, then can the app emit it's own event in the on connect event, something like emit getRemoteValue, and then it receives whatever the current remoteValue data is? While I think that could work in theory, I guess the websocket would need some kind of scoping handling, so when the client emits getRemoteValue, the websocket doesn't redundantly re-broadcast the remoteValue event to all active clients, but only to the client that requested it.

2. How can mobile apps guarantee that the remoteValue is kept up to date while the app is playing in the background, or the screen is locked? My understanding is that a mobile OS may pause or disconnect the websocket connection whenever it wants, and if that happens, it is a rather serious problem, because what if the app gets stuck on a specific remoteValue for an hour, sending sats to that music artist, even though multiple other remoteValue events have been sent over that time, but missed by the app because the websocket is paused? While keeping a websocket connection active while in the app is in the background for a mobile OS may not be reliable, I believe mobile OS can more reliably make polling style requests on-demand for every X seconds of playback. Should a polling-style endpoint be recommended in the spec?

I'm not sure, but I think the answer to problem 2) might be the same as the answer to problem 1). Maybe mobile apps, while in the background, could convert into a "polling" remoteValue mode, which briefly connects and disconnects from the websocket every X seconds of playback, and gets whatever the current remoteValue is in the process.

Polling does not sound as efficient as an active websocket connection would be, so I'm not sure if polling is tenable for this purpose, but it is also only a tiny amount of metadata being requested for remoteValue, so maybe it could be an acceptable solution?

Anyway, I'd appreciate your and anyone else's thoughts on how we might be able to address these problems within the spec.

[agates]

You can run a websocket connection in a background service on Android.

That's essentially what's already being used for UnifiedPush support, it's just not implemented by Podverse at that layer.

[agates]

And technically you can tell socket.io to only use HTTP long-polling, but I think that would break without being in the background anyway.

[mitchdowney]

@agates can you explain a bit more why long-polling in the background would break? What if we were long-polling on iOS every 10 seconds while in the background? iOS allows you to run functions in the background as long as the media player is playing. It's one of the exceptions to their limitations as I understand.

[agates]

@agates can you explain a bit more why long-polling in the background would break? What if we were long-polling on iOS every 10 seconds while in the background? iOS allows you to run functions in the background as long as the media player is playing. It's one of the exceptions to their limitations as I understand.

Long polling is expected to last a lot longer than 10 seconds. And I don't know if you have that level of control with socket.io. I'm specifically talking about socket.io.

[mitchdowney]

I just checked the socket.io docs and one of the first things it says is it offers HTTP long-polling as a fallback. I can run some test cases using the live-updates repo that @thebells1111 created and see what happens.