sandroJust thinking about the difference in client-server protocols between mastodon and ap. Huge difference: AP is extension neutral; you could have an AP server that handles posts with details it didn't understand; not so with Mastodon.
sandroGargron, I'd propose the UI only displays what it knows how to handle. Everything else gets ignored. And new things can say "if you understand me, then ignore X, since its the fallback for me". This is extensibility; without it, the system is basically as constrained as the silos are.
sandroReally? I don't think extensibility can practically be deployed in a decentralized system without fallbacks. Without fallbacks, using an extension is a painful choice, because you're excluding a huge chunk of your audience.
sandroFor example, if I want to survey my followers, I can either post a link to a survey website, or use an in-post survey extension. With fallback, I can do both and reach everybody. I'd probably have to be brave or foolish to use the extension, in its early days, because I wouldn't be reaching many people
sandroyeah, that clearly doesn't actually work in the real market. polyfills (fallbacks) are what have allowed modern browsers to finally start evolving.
sandroYou have to empower the person posting it to craft a suitable fallback they're comfortable with, other wise they're never going to use anything new for something that is actually important.
sandroI think AS2 works here, because an extension (eg a survey extension) can just be some added properties on the fallback post. This thread started because I observed that the Mastodon c2s API doesn't allow things it doesn't understand (ie extensions).
sandroOr response-types (I see Facebook just added a new one today). Or checkins. Or item-of-sale posts. Or ride-sharing (for a decentralized uber). Or ... pretty much anything else we do with apps today. :-)
cwebber2sandro: you may remember that, after much discussion, we agreed that posting a non-activity object to your outbox in c2s means that the server will automatically wrap it in a Create
cwebber2eg, maybe "3dVideo" is a subclass of Video, but using both means that systems that don't know about 3dVideo's property of saying "put on your 3d glasses!" can still play the video meaningfully
tantekadding new user-level "types" to a system like this is definitely non-trivial and takes some forethought (for it to be workable at all). the multi-typing that cwebber2 suggests is a good start
cwebber2the problem with the whole multi-typing thing is that it means that users who expect to use java/ruby/python like classes to represent as2's type heirarchy will be very confused when it turns out an object can have multiple types at the same time :)
tanteksandro, regarding whether we don't know how to do extensibility, or fallbacks, whether or not the spec says how (or not), the really proof of this (either way) is when implementations try to actually build extensions in a hetergenous community of implementations, and see what happens. do they figure it out or not?
tantekvery rarely (like never that I've seen?) has any "extensibility / fallback system" that was designed "up front" actually survived that kind of real world stress test
tantekso we won't really know for AP, until we have like at least 3+ impls in use in the wild by real users across servers, and some impl decides to make up a new type and add it and see what happens to the other impls when they federate
tantekbecause at "small" numbers, there's a *chance* that all the impls can upgrade something simultaneously, but rarely does that dynamic last in any successful standard
tantekin the indieweb world, it's been interesting seeing the extensibility/fallback evolve from replies -> likes -> reacji for example, multiple generations of extensions / fallback as were
sandroHTML gets extensibility/fallback good enough. (clients MUST ignore attributes and elements they don't understand, and MUST use the content of elements they don't understand. That allows for fallback.
sandroI agree HTML has problems, which is why I said "good enough", not "right". If it didn't get them "good enough" it would have died a long time ago, I expect.
tanteknevermind <object> tag etc. I mean works in Firefox sure, but cross-browser interop is poor. and without interop, you don't actually have extensibility
sandroMeanwhile, it sounds like AP is hostile to fallback, so if I were someone who was interested in application areas other than cloning twitter and facebook, that hostility would be enough to make me lose interest in AP.
tantekyou don't need all impls to get it right for it to work out. we've learned that in indieweb. it's ok if it starts out with a few figuring out fallbacks and then eventually it picks up or it doesn't. it's not automatic failure / hostile.
Gargron sandro: this is on purpose, it's really hard to design a good UX around completely arbitrary payloads
sandro For example, if I want to survey my followers, I can either post a link to a survey website, or use an in-post survey extension. With fallback, I can do both and reach everybody. I'd probably have to be brave or foolish to use the extension, in its early days, because I wouldn't be reaching many people
tantek sandro, regarding whether we don't know how to do extensibility, or fallbacks, whether or not the spec says how (or not), the really proof of this (either way) is when implementations try to actually build extensions in a hetergenous community of implementations, and see what happens. do they figure it out or not?