#social 2020-07-29
2020-07-29 UTC
# 
heluecht[m] It seems as if Mastodon now requires a signed HTTP request to fetch activities. Does Mastodon now requires signed requests for every endpoint?
jussi joined the channel
# heluecht[m] For performance reasons - and because not every request is done in behalf of a dedicated user - we had used signed requests not in every situation.
# heluecht[m] I did some further testing and saw that signed requests are also have to be used when fetching account data. Without a signature only the minimal amount of data is returned. Since when did this came to effect?
# heluecht[m] Ah okay.
sl007 joined the channel
# nightpool[m] heluecht: to explain in a little more detail: Mastodon has a setting, which a few instances have enabled, that requires HTTP signatures for the majority of GET requests. this makes it possible to enforce whitelists/greylists/blacklists of which instances can see your posts
# nightpool[m] I don't think signed GET requests is much of a performance issue for the requesting server—the vast majority of http requests are already signed, because they need to be, we're just filling in the last couple of percent
sl007 and Grishka joined the channel
# Grishka Hi. I'm reading the specs again, and I'm having trouble understanding the relationship between objects and collections they're part of.
# Grishka (this is a more generalized question than what I asked here https://socialhub.activitypub.rocks/t/collections-that-are-modifiable-by-actors-other-than-their-owner/815 earlier)
# Grishka Suppose I have photo albums. Those are, obviously, collections. I add a photo to an album, so it becomes part of that collection.
# Grishka As per the spec, I'm supposed to specify that as `target` in the activity that added it — for example, Create
{Photo}.# sl007 Or you create it first and "add" it later https://www.w3.org/TR/activitypub/#add-activity-outbox
# Grishka This does work for those servers that would receive the activity, but it's impossible to know what the object is part of when you have ONLY the object — you need the activity as well.
# Grishka But the spec says that `partOf` is only for collection pages.
# Grishka Even though it's a good fit for what I'm trying to do
# sl007 Why don't you use the "add" activity?
# BradKoehn[m] Objects are not required to belong to exactly one collection. They can belong to zero or more collections.
# Grishka > Why don't you use the "add" activity?
# Grishka because that still makes the object not self-contaned
# Grishka So suppose someone fetches that photo using a direct link they pasted into the search box on their instance. Their instance will only receive the photo object, but none of the related activities that determine the collection(s) where it belongs.
xbdf joined the channel
# Grishka In fact, it has no way whatsoever to retrieve those activities even if it wanted to
# BradKoehn[m] Collections are unidirectional aggregations, so that's the behavior as specified, yes. There's literally no way to go from an object to its collections, because objects don't have to be a part of exactly one collection. If you want to add that as a constraint to some of your objects, go ahead and extend the specification.
# BradKoehn[m] … but there's nothing that prevents one of my users from adding an object on your server to one of their own collections.
# Grishka That's not an issue — what I want is to give the object owner the ability to specify a collection (photo album, group wall, whatever) where the object belongs, so other servers can fetch the rest of the collection if they wish to show the object in its intended context, or to allow going from a single photo to its containing album.
# Grishka Or from a post to its containing group.
# Grishka Also edge cases. If you follow someone, and they post in a group where you aren't a member, but then you fetch that post via a direct link, your server needs to know that the post belongs to that group so as to not show it in your feed.
# BradKoehn[m] Sure. Add an extension field. If a server knows about the extension, it'll know to look for the field and what it means. Otherwise it will ignore the field.
# BradKoehn[m] I don't think the edge case you describe is achievable. If a server fetches a post (successfully), there's no way for it to know that the user shouldn't see it: if they shouldn't see it, their server shouldn't have been able to fetch it in the first place.
# xbdf it's not about privacy, groups are a weird case where at least _some_ users might not want to see those posts unless they're looking at the group
# Grishka Yes, it's exactly that. The post is public but not intended for user's own followers.
# xbdf actually that should probably be communicated by omitting the followers collection from `to`
# Grishka And, actually, you can specify collections in to/cc...
# Grishka Yes, was about to say that :)
# heluecht[m] > <@nightpool:cybre.space> heluecht: to explain in a little more detail: Mastodon has a setting, which a few instances have enabled, that requires HTTP signatures for the majority of GET requests. this makes it possible to enforce whitelists/greylists/blacklists of which instances can see your posts
# heluecht[m] Only thing is that there are request that aren't done behalf of a user, so the system has to use *some* user.
# xbdf most implementations have resolved this by creating a "system" user