This is the part that I find somewhat unfortunate about Peertube. This means that only ActivityPub clients that support WebRTC will be able to access Peertube media. Right now, I think this basically means just modern web browsers. It bothers me somewhat that an early, potentially major ActivityPub service is going to limit full functionality to the few existing major web browsers. That's the opposite of what I want from a federated protocol. (Someone correct me if I've got any of this wrong.)
Regardless, Peertube seems awesome, and I hope we keep seeing more and more services built on ActivityPub.
ActivityPub defines federation messages server to server and client to server. It is not a protocol per se, and rather a message exchange standard, which could perfectly be used only between servers, as is the case with federation of videos between PeerTube instances, and more recently for video comment feeds, that can interact with the larger fediverse (Hubzilla and Mastodon so far were tested).
In no way it defines how you access media. That is defined by the use of WebRTC, which is supported by a growing number of browsers, and anyway provides a fallback to direct streaming (HTTP), so that any browser can interact.
> and anyway provides a fallback to direct streaming (HTTP), so that any browser can interact.
Ah, that's awesome. That definitely assuages my fears somewhat.
> [ActivityPub] In no way it defines how you access media.
ActivityStreams (which ActivityPub builds on) does define an attachment property for messages [1]. Is this not a standard mechanism for clients to access ActivityPub media (via the attachment's type and url)?
It is, but I don't see how web browsers would need to interact directly with ActivityPub. That's just a way to settle on a json structure everyone will be using in their web application (that acts as AP client), as is the case in Mastodon.
Here with PeerTube the client interface doesn't interact with AP to watch videos or get them. It just requests the list directly to the server.
WebRTC libraries exist outside of browsers. What video-capable software are you hoping to use this with that isn't a browser and isn't able to be wired up to a library?
My concern isn't about any current AP clients; it's that we'd be cutting off a whole dearth of potential future AP clients by making it the general expectation that all viable AP clients support WebRTC, and thus the task of building a client goes from the relatively simple "support json over http" to "support those + WebTorrent/WebRTC", which (despite what you say) isn't trivial (unless the client is in-browser/webview). Even if "just hook up a library" were a viable solution, the requisite increase in complexity/LOC/bugs would be really unfortunate. If this were the case, it seems to me we'd lose a lot of potential future diversity in AP clients.
I'm having trouble finding any complete WebRTC implementations outside of browsers, do you have any examples?