For every complex problem in the field of decentralized network engineering, there is an answer that is clear, simple, and wrong:
-
For every complex problem in the field of decentralized network engineering, there is an answer that is clear, simple, and wrong:
-
@silverpill care to elaborate?
What is wrong with those things existing as auxiliary services?
-
None of those things need an external provider.
There is also an EEE aspect of it, because they use custom API instead of ActivityPub.
-
@silverpill @mariusor what about cross-instance (opt in) Search? That kind of does need to be an external service, no?
-
@silverpill OK, I see. In this case I agree for some of them, but not all.
I was thinking more of pluggable libraries or services that can be pipelined into an ActivityPub server flow.
-
@dmitri @silverpill personally I'm of the opinion that whatever people publish as a public ActivityPub activity/object is fair game for doing public things with it, including search or dissemination in other formats: RSS, calendars, bridging to other networks, etc.
-
-
@silverpill isn't that pretty redundant? On multiple levels even... one: collections should be accessible through HTTP, two: if a server is interested in content from another server AP already has ways of modelling that in the vocabulary.
-
@silverpill @mariusor wait, but that relay you're describing - that's an auxiliary service
-
@dmitri the way I understood what
@silverpill is saying is that if those are part of the same server ... they're not "auxiliary". -
