Back in the long, long-ago we came up with the concept of timelines and (semantic) inboxes, the idea being that you could have a web version of your email inbox, but that it could do more things. Outboxes came a bit later
One idea for inbox/outbox was as a processing or “staging” area, before things get posted onto your timeline or notifications area. These were to include more things than just posts, even things like actions or payments
The timeline was similar to facebook’s or twitter’s timelines and would be a list of things displayed for each user according to chronology and permissions to view. I dont know if you’d call this a timeline or social feed or something else
Your activity stream was something on top of this that was like a meta commentary for changes. “Alice just liked your Post” etc.
I’ve been trying to work out how this is all implemented today in the fedi. It seems to me that it’s, to some degree, up to the implementer, but also that outbox and timeline are sometimes overloaded, to be the same thing
I’ve been reading the older thread here which is helpful, it would be great if someone had some more pointers or insights on how this works today
I did a FEP about posting things to places other than your timeline/feed. Initially for walls, and Smithereen implements it for walls right now, but could be useful for much more.
For some implementations, like mine, it’s technically challenging to have all actor’s activities in outboxes. For example, I store likes in a separate DB table from posts, and I’d have to merge that all somehow and be able to paginate through it. Only for the client to probably split it back apart.
@grishka While I like the FEP (and redaktor implements it), the question would then be about
each user according to chronology and permissions to view
In the FEP it is a public collection while I think @melvincarvalho s question comes down to the unsolved use of “Groups” in the Fediverse (where multiple non-interoperable solutions exist).
So, in redaktor you can share public with “blocks” on your webpages cause the webpage itself is an AP Service Actor. But this is maybe not ideal …
When is comes to permissions, nothing is stopping you from serving a different view of the collection for different users. Authenticated/signed get requests are part or the core AP spec.
Yes, of course, no doubt.
The difference was that with the Service Actor we can make others to follow only this Collection.
If I would have an Inbox and a flowers-collection and a lomo-collection, how could others follow only the flowers?
Hm. That’s an interesting use case indeed. I don’t think you can follow something that isn’t an actor. But, I think Pixelfed allows you to follow hashtags the same way as Instagram does? @dansup how did you do that, or is it fully local?
I’ve seen that name, and I’ve probably seen that website, but I’ve yet to see anything concrete like a running instance I could poke into and try to federate with.
According to the AS vocabulary, “Follow” isn’t restricted to actors. FWIW, we use it internally for following and unfollowing conversations and I’ve been considering using it federated to follow changes to collections such as photo albums. This would be perfectly legal usage from my reading of the spec.
Authenticated/signed get requests are part or the core AP spec.
Not really. We couldn’t come to agreement on signature mechanisms in the rush to get the spec out the door by some arbitrary deadline; and this was published in an auxiliary security best practises doc if I recall correctly. At the time it was completely optional (only if security was involved) but over time more and more projects made it mandatory and different projects threw their weight around to mandate exactly which headers needed to be signed and the rest of us were more or less forced to go along since federation with those projects would break completely if we didn’t. In fact this happened. There was no public discussion beforehand.
