@mariusor@metalhead.club cover
@mariusor@metalhead.club avatar

mariusor

@mariusor@metalhead.club

Mostly a programmer.

Implementing #ActivityPub in the #Go programming language.

Current projects:

  • #GoActivityPub - a library to use ActivityPub in Go.

  • #FedBOX - a generic ActivityPub service supporting the client to server API.

  • #brutalinks - a link aggregator inspired by (old) reddit, hacker news and lobste.rs built on top of FedBOX.

  • #oni - a single user ActivityPub server with minimal fuss.

My posts are mostly related to ActivityPub and web development.

This profile is from a federated server and may be incomplete. For a complete list of posts, browse on the original instance.

BeAware , to random
@BeAware@social.beaware.live avatar

Kinda strange when people complain about something that's easily explainable and understandable...😳

How can an instance count followers and following from instances it doesn't know about or instances they block? They can't...soooo.....stop complaining? Cause I don't see how it could be done reasonably.

It's like you not knowing every single person in the world. It's not feasible, so stop worrying about it so much....

RE: https://sakurajima.social/notes/9v7up800mf

mariusor ,
@mariusor@metalhead.club avatar

@BeAware I think you misunderstand the problem. The ActivityPub specification encourages implementations to expose a followers/following collections on actors. Those collections have a TotalItems property in them which should allow anyone to see the count.

Here's an example.

mariusor ,
@mariusor@metalhead.club avatar

@BeAware federating between instances should have nothing to do with it.

Dan is presenting a feature where a user views another profile and then they can see mutuals. This can be done if Mastodon would load all the information (including follower list) about the profile when you view it from your own instance, instead of relying only on data that has been previously federated.

It's a trivial feature that Mastodon is lacking, and I feel like that's what the toot you quoted complains about.

mariusor ,
@mariusor@metalhead.club avatar

@BeAware I don't know to be honest, it's possible that other clients don't take advantage of the information. But as the owner of a mastodon account, that's the one that annoys me the most. :D

hrefna , to random
@hrefna@hachyderm.io avatar

"Meta also can’t promise that when you delete a federated post on Threads, it will also get deleted on the other platforms it was shared on"

I mean that's just the fediverse in general, especially with how it works today. Even the ActivityPub spec doesn't make a strong statement on how this is supposed to be handled ("should remove it" from public view is not "must delete it").

mariusor ,
@mariusor@metalhead.club avatar

@hrefna I don't follow your math here. I read this as: you sent 2000 Create activities, then you send 2000 Delete activities to the same recipients. EOT

mariusor ,
@mariusor@metalhead.club avatar

@hrefna @jenniferplusplus it sounds like what you want is "Undo", not "Delete".

mariusor ,
@mariusor@metalhead.club avatar

@hrefna lol. :) I have the excuse that I just woke up, but still...

mariusor ,
@mariusor@metalhead.club avatar

@hrefna @jenniferplusplus

I think that's for the simple use case, where you want just the object to be gone. When you want all the "meta data" surrounding an object to be gone also, including its created activity I think that's exactly the way to go.

hrefna , to random
@hrefna@hachyderm.io avatar

From the standpoint of the principle of least surprise, what would you expect—not in terms of mastodon's implementation, but in general—the difference would be between:

  • to: as:Public
  • cc:as:Public
  • audience:as:Public

Are they identical, would you expect these to manifest different behaviors? Which would you view as correct?

mariusor ,
@mariusor@metalhead.club avatar

@hrefna first two I treated as "this activity needs to go in all the local inboxes that the server knows about". I never used (or seen used) the third.

On another note I also use the presence of the public namespace in the recipients list as a way to allow public access to objects in collections, which could be said that can be better served by this third option.

mariusor ,
@mariusor@metalhead.club avatar

@jenniferplusplus @hrefna I mean, the spec specifically invents this usage for the public namespace:

https://www.w3.org/TR/activitypub/#public-addressing

Note "addressing" in the verbiage, which to me implies the To/CC/Bto/BCC properties not "audience".

mariusor , to random
@mariusor@metalhead.club avatar

Hey devs, what do you think about my SQL document storage table for ActivityPub objects?

https://github.com/go-ap/storage-sqlite/blob/master/init.go#L46

The dialect is SQLite, but Postgres supports all the features used here: virtual and generated columns, and json_extract.

I don't know about MySQL, but if someone can chime in about it, I'd love to hear from you.

mariusor OP ,
@mariusor@metalhead.club avatar

@hrefna indeed querying on fields that could be arrays or single values is a bit of a pain (at least in sqlite) it requires unions.

And yes, collections are a mess, they're in the process of being improved.

mariusor OP ,
@mariusor@metalhead.club avatar

@hrefna

  1. yes, the items column of the collections table stores an array of iris.

  2. I haven't tested how the content maps would work in this setup yet.

  3. Addressing on actors (like on the other objects) is used as a simple ACL. If the recipients list includes the Public namespace, then it's visible to non-authorized requests. If it does not, it's only visible to requests containing a valid HTTP-signature/OAuth2 Bearer token from one of the recipients.

hrefna , to random
@hrefna@hachyderm.io avatar

This is actually a good example of something that really bothers me in / AS2 /

From a security standpoint and from a performance standpoint there is a world of difference between replies returning:

  1. A list of references
  2. A list of Links
  3. A list of Objects

But from the standpoint of AP/AS2 there is no difference between these. They are all the same, and the documentation provides no guidance on navigating this.

https://hachyderm.io/@hrefna/111948881587271611

mariusor ,
@mariusor@metalhead.club avatar

> But from the standpoint of AP/AS2 there is no difference between these.

@hrefna I think it's because AS/AP cares not about efficiency and performance. They employ the logic: you encounter an IRI, you dereference it, therefore servers/clients should only deal with the objects, no matter how they've been obtained.

hrefna , to random
@hrefna@hachyderm.io avatar

In , which aspects do people prefer (this is going to be a thread), these are not all mutually exclusive:

  1. The replies collection is a canonical list of identifiers for posts that have been accepted. Servers may aggregate based on inReplyTo, but they SHOULD check periodically to make sure that those replies are in the canonical list for that post.

  2. The replies collection is a canonical list of links to the posts.

  3. The replies collection is not canonical.

1/

mariusor ,
@mariusor@metalhead.club avatar

@hrefna dunno about a), but for b) there's no need to complicate matters with adding Reject semantics for replies. Bob is in control of the /replies collections of his objects, he should be able to Delete any item that he finds displeasing.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • test
  • worldmews
  • mews
  • All magazines
    •