But Plume supports Markdown, while Mastodon doesn't. I don't know for Pleroma but you get the idea.
How would the client know what the server support in terms of features?
Funkwhale and PeerTube instances deal with Audio and Video media, respectively, PixelFed with images, Mastodon and Pleroma with small-to-medium text, Plume and Write.as with long-form content, etc.
Do you think it's possible to provide a unique and comfortable experience for all those projects ?
The big secret here is that I'd asked "everyone other than Chris" to answer the question at FOSDEM, it's because I'd already asked them this exact question on IRC a month before and they suggested using streams exactly in this way. The reason I didn't want Chris to answer was I was curious to knew what the implementers were thinking (and I already knew what Chris would be likely to say).
@emacsen @cwebber @eliotberriot @kity my take is more that the current "non-generic" implementations are actually a really bad fit for the c2s api, precisely because they do so much validation server-side. an xmpp-like extension system would quickly become confusing. server feature discovery isn't part of the c2s spec, is it? afaik a lot of that stuff seems to be handled by nodeinfo in the wild.
Maybe I misunderstand the issue but I think part of it is that right now people are okay with having N ActivityPub identities in a way that mirrors their proprietary service life. "Mastadon, PeerTube, Pixelfed" each on their own. But if you moved the bar the other way, to each of those being some sub-stream of your general AP identity, then you'd insist on a client (or c2s model) that was flexible enough to handle it.
@emacsen @cwebber @eliotberriot @kity yeah that's very much a big part of it, people are looking for "alternatives" and it's easy to promote something as "federated [x]" where everything fits your internal model. it's also easier to develop an app-server than it is a generic one. the server does all the heavy lifting, and you can define an app-specific API for handling just the data the server can process. it sidesteps the problem of server capabilities almost completely, that's the API job now
@emacsen @cwebber @eliotberriot @kity of course there's the new problem: which API methods does a server support? what are the limits of each API field? and that's part of the design of the API rather than the design of the server. hence why modified masto or pleroma servers run into issues with the masto API. the server needs to report info about itself a la /api/v1/instance
Thinking about the issue of the poor state of C2S ActivityPub, implementations, maybe the thing to do is make a new AP client (without a server) that does what we want and is designed to be flexible, and then see which servers support it.
The only big downside I see is that AP doesn't have a standard authentication mechanism, but maybe that can also be modularized and abstracted.
@yvolk @andstatus @thefaico @trwnh @eliotberriot @cwebber Thanks for your thoughtful explanation, I'm not sure everyone mentioned here wants to be part of this discussion but it's an interesting one for me!
I use the term "identities" specifically to reference the "id" property of the AP spec.
And some of the technologies you mentioned (Webfinger in particular) are not part of AP, so I think it's important to mention that.
What I hear you saying is that you think Webfinger is the place to tie streams into, rather than AP itself,. but the AP spec has a section on secondary collections, which is where I would imaging having these. A secondary collection be a reference to another actor. You *could* do that in Webfinger, but you could do it in AP as well and I see no reason not to.
In what way do you think Webfinger is more appropriate?
@eliotberriot @kity @cwebber *maybe*? i'm not sure to what extent xmpp servers store data and how, but i'd say probably in the sense that email servers can host your emails and xmpp servers can host your messages.
a generic AP server would at minimum handle delivery of AS documents generated by the client -- the recipient can parse and validate, perhaps the server can tell the client whether the response was 200 OK or if there was some error (i.e. "was this message delivered successfully?")
@eliotberriot @kity @cwebber so in that sense it would be delivery server only (like SMTP) but then one step above that would be to have the server also manage data *storage* and not just delivery (a la IMAP).
in that case, the server stores your inbox and outbox and all the AS documents and Activity stuff, and allows fetching the content on valid GET requests. but there is no standard authentication/authorization flow, so we're kind of limited to allowing public fetching if we want full compat
@eliotberriot @kity @cwebber as far as the client would be concerned, the generic Server doesn't have a way to dictate limitations. but rather, the client would fetch only the AP documents that could be validly displayed within that client. so if the client wants Note objects under 500 characters, it would get your inbox and filter for Note type, then filter for length.
that's kind of wasteful i guess? which is why most AP projects chose to reject incoming Activity that they don't understand.
mastodon.eliotberriot.com is one server in the network