Ormai ho deciso che abbandono #writefreely per il mio blog sto già lavorando al nuovo sito.
Fediverso
2
Posts
2
Posters
7
Views
-
Ormai ho deciso che abbandono #writefreely per il mio blog sto già lavorando al nuovo sito. Riguardo all'integrazione con il #fediverso ci ho pensato un po', ma credo che l'opzione migliore sia di condividere direttamente dal mio profilo i nuovi articoli. Se si vuol seguire solo il sito in modo automatico ci sarà il feed.
-
Ormai ho deciso che abbandono #writefreely per il mio blog sto già lavorando al nuovo sito. Riguardo all'integrazione con il #fediverso ci ho pensato un po', ma credo che l'opzione migliore sia di condividere direttamente dal mio profilo i nuovi articoli. Se si vuol seguire solo il sito in modo automatico ci sarà il feed.
@magostinelli in effetti writefreely pare un pochino in stallo da qualche anno a sta parte.
Per la federazione del blog non saprei, in effetti Mastodon è molto più diffuso e si riesce a far girare l’articolo molto più velocemente rispetto agli account del blog federati.
Però ci potrebbero essere persone interessate solo al blog e meno alle che chiacchiere da social che fai su mastodon.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@smallcircles@social.coop I feel personally called out for this 😛
-
#ActivityPub builds on top of #ActivityStreams in the sense that it adopted a number of its 'social primitives' defined in its vocabulary, and Collection being among those. These particular uses become 'protocol space', but other than that AS from the perspective of AP solution development is purely a set of social primitives, granular building blocks that one *may* use in a solution. AS is a utility library of sorts then. Or is that a wrong perception?
A 'feed' is something that lives in solution space, and I would only choose Collection to model it, if it offers a perfect fit in functionality. And aboveall.. does not assign some new app-specific use along the way.
I tooted today that I feel the biggest folly of the fedi is that everyone tries to cram their domain into the AS namespace. The AS primitives should not be Swiss army knives and have only singular well-defined meaning and purpose, yet they have become that along the way.
-
I haven't seen anyone use Add and Remove activities to notify updates to the `outbox`. I don't think it would work; it's too recursive.
I've done it for other feeds, like `replies` or `followers`, and it works pretty well.
-
I might not understand what we're talking about.
@smallcircles said that AP doesn't mention "timelines" or "feeds". We use a different term, collections. They are ordered in reverse chronological order, like what most people expect a "feed" to look like.
-
@evan@cosocial.ca gosh I can't imagine assigning Add and Remove activities for a "popular" collection. It changes so often that it seems a waste of resources to try to track it.
Dynamic Collection?
Or as @smallcircles@social.coop said, even just light algorithmic ordering in a timeline makes stuffing it into a collection unwieldy.
-
Except when they are called other names instead ;p
A timeline is a different thing than a collection imho. And an AS collection has some very particular functionality, which if I model a timeline in my app may not supported (e.g. reverse ordering).
Collection / 'timeline' is one of those words where sometimes they indicate an app domain, and sometimes a core protocol mechanism. Same is true with 'follow' which is sometimes a user action, sometimes indicates low-level publish/subscribe.
For core capabilities that must be part of the specs, in 'protocol space' it may be better to use terminology that is more common in messaging architectures and all the various architecture patterns that are involved. Perhaps idk we deal with a time-ordered event log or something like that.
-
@smallcircles @julian @deadsuperhero we call them collections.
-
Can't help but wonder about terminology use and abstractions they indicate. Nowhere in the specs is there mention of 'timeline' and neither of 'feed' (except as example use in AS).
I feel we started with powerful specs to be able to model *any* social networking use case. But where the specs had blanks gradually the impls filled these in with leaky abstractions such that fedi is now hammered into a very narrow social media microblogging domain.
If an app needs "Timeline" and "Feed" concepts, then it should model them. Given the actor-based nature of AP they might be actors, or whatever is best. These concept are about solution development, i.e. what is built on top of the protocol, and not indicative of core protocol capabilities.
There's so much confusion on "where does the protocol end vs. where does my app design start".
SDK's should offer "Addressable actors exchanging msgs with object payload", and hide all impl details for the solution developer.
