@gothiccard The Kobo. Hardware is a little more open than Amazon's, it supports more formats, and, if you care for these things, it doesn't put money in Bezos' pocket. It does have the downside of the online shop being less streamlined and with less saving opportunities because Amazon strong-arms publishing houses and authors, but to me that's an extra point to support the little guy.

@steve "valid" as in it triggers no failure cases: probably. "valid" as in someone knows what to do with it: probably not.

I base this on section 5 of the activitystreams core spec: https://www.w3.org/TR/activitystreams-core/#extensibility

@hongminhee why does it require authorization though? Information for developers should be free. Allow use of some authorization/cookie header maybe, but let the decision for the consumer.

People that are interested in having authorization in front of their dev docs probably already have an authentication/authorization means.

@pid_eins I understand, I think I was asking more in the idea of this SAK message having to be secured some way against being intercepted by malicious listeners. I guess I don't really know enough about the situation to actually form a pertinent question, sorry.

@pid_eins is DBus robust enough for this kind of security mechanism? I would have thought that systemd can do something more drastic like freezing all sessions and switching to a "login" target (speaking as someone very far out the sidelines)

@gabrielesvelto I think Moldova is more likely to be targeted. Small country, small population, many nationalistic Russians in Transnistria.

They recently voted into office a very EU oriented president in the form of Maia Sandu, so it's probable that the possibility weighs on people's minds.

@ChristianKrebel I doubt there's any practical need to bolt some payment related vocabulary on ActivityPub.

The Fediverse is not suitable for disseminating very sensitive information like payment data so it's wiser to keep it orthogonal. Instead I think services should allow individually integrations with _existing_ payment providers.

Liberapay would probably be the best choice, as it has similar ethics and goals as most Fediverse projects.

Sure we can add an activity/object as a congratulatory side-effect: "Bob paid/subscribed/cheered for Alice", but that should be just cosmetic.

The full(working) example can be found here: https://pkg.go.dev/github.com/go-ap/filters#example-AggregateFilters

#activitypub #GoActivityPub #golang

The new API would not be terribly different.

Frantic day today, around 10h of productive work on improving the Index and moving it as part of the go-ap/filters module.

+1510/-11 lines of which 987 belong to tests.

Coverage is not entirely sufficient yet, because it's missing the checks for the top level Index.Add() and Index.Search() methods.

Another thing left to do is the persistence to disk.

The **reason** why I wanted to move the work I've done yesterday to this module is that instead of the custom client.SearchByX() functions, I wanted to retrofit the existing functionality already present in the filters module. Ah, also moving the bitmaps themselves to a semblance of generic types....

@helge for servers that aggressively cache media (like Mastodon for example) it's at best misguided to worry about raw json size.

@hazelnoot @jenniferplusplus

@jenniferplusplus there's no formal specification for activities addressing because, like I replied to Helge, it's up to the author and their client to determine whom it gets delivered to.

That's why the specification tells us about what happens when receiving objects/activities with inReplyTo populated, but not how one finds where to send them.

To me it makes perfect sense, but I'll grant you that I might be missing things.

@helge addressing is up to the client. In my opinion there's no "wrong" way to do it. The authors of the Activities should be the ultimate arbiters of whom receives it. The fact that Mastodon (and most of the clients) in the fediverse hide this option is the *actual* problem in my opinion.

@jenniferplusplus

@jenniferplusplus sorry to be an ass about this, but it feels like you're not cooking with your heart.

It's not spelled out for us but it's clear from reading the spec(s) that the message needs to be "sent" from the server where the reply comes from to the server where the original is. Therefore the client of the reply guy actor needs to add the original's attributedTo actor to the list of recipients if it wasn't already there.

Anyone else would know it happened if they were also in the recipients list, or when their client retrieves the replies collection of the original.

@jenniferplusplus erm.

The replies collection[1] present on Objects contains (what to me looks like) enough information for establishing the relationship between a received Object's inReplyTo property and the replies collection itself.

Is that too little information for your needs? What else do you require?

[1] https://www.w3.org/TR/activitystreams-vocabulary/#dfn-replies

@jenniferplusplus I guess you're right, but in my opinion you're overcomplicating things.

I don't think that a distributed permission system would make the system better.

The canonical representation of the reply collection of an item is what you get when you query that item's reply collection IRI. That's it. What's in there is the "truth".

IMHO nobody needs to "know" if a remote server can add things to it, because the mechanism through which this happens is not governed by anything else but the server where the collection is hosted.

By *native* I mean that I can have my own little API for searching:

I'm sure I made plenty of mistakes, but I have to admit I find it surprisingly satisfying to be able to operate on a data type that I can overlay on top of the existing #FedBOX storage engines and get native and *fast* querying for them.

The indexes are quite chunky despite being built on top of roaring bitmaps because there's so many "indexable" elements in an #ActivityPub object. (Currently I'm indexing the type, the content, summary, name, preferredUsername, the recipients, the actor and the object)

As I explore some more, I hope I streamline some of these issues, and make the whole thing more robust.

> how one is supposed to ask permission to reply to someone else's post.

@jenniferplusplus I think about this problem the other way around.

If someone does not have permission to reply to my thing, my server will reject the activity that does so, or my client will remove the reply from the reply collection.

Since I'm such a fan of handmade programming, I find myself this fine eve implementing document indexing from scratch(ish) for my #GoActivityPub library storage backends.