@puppygirlhornypost2 @hrefna @benpate
I get why people are doing it. It's the thing that would make AP an actual protocol. But only if it was done in advance, at design time. So that implementing the protocol meant producing and expecting those behaviors.
I don't think you can get from A to B with FEPs. You have to start fresh, with a successor protocol that actually defines those behaviors.
@jenniferplusplus @puppygirlhornypost2 @hrefna @benpate the issue with writing a new protocol instead of extending an existing one is that it isn't worth anything without anyone actually using it, and getting software developers to implement a completely new protocol instead of adding extensions to their current implementation is a much more difficult task
@lily @puppygirlhornypost2 @jenniferplusplus @hrefna @benpate
Think its worth looking at the PDSes from ATProto here. Adverse Interoperability is a thing, and the Bluesky people are actually not that adverse at all currently to experiments. If you're looking to extend a protocol because of the value of the userbase, atproto might be just as logical of a choice.
thinking in this direction https://berjon.com/ap-at/, but instead of AP its a modified version of AP
