Follow

Anybody else having problems with commenting on videos from Mastodon? When trying to fetch a video like conf.tube/videos/watch/6289920 from Masto by URI, I get a 403 error.

/cc @rgggn @sl007

@schmittlauch @rgggn @sl007 It seems this video has been posted with what in Mastodon translates as direct visibility

@schmittlauch @rgggn @sl007 Current JSON representation on the origin seems to be public. I wonder if visibility on PeerTube videos is mutable and someone fetched the URL before it was made public? Mastodon does not support updates like that.

@Gargron Earlier today around 12:00 UTC I did successfully fetch conf.tube/videos/watch/4102f53 and comment on it. But around midnight UTC I tried to fetch the keynote and it failed with 403.
Has anyone of the publishers or peertube admins changed anything in that period? @mlemweb @rgggn @sl007

@Gargron It also worked for me back then, and now my instance has it cached anyways.
But if something had direct visibility at the first fetch attempt, that fact is cached (forever?) by Mastodon, correct?

@Gargron @schmittlauch @mlemweb @rgggn

Thanks for looking into it!

Right, this is my talk and it is one of only 3 videos showing up. Click here to check -> @apconf

Let me explain:
We collected all videos on peertube unlisted.
A new user thinks of this as "unfederated".

Then when all talks arrived we set them public.
A new user thinks, this means "federate public" but it did not.

Mine is a replacement talk for another one dropped out and so I published the 3 last ones directly public …

@sl007 @Gargron @schmittlauch @mlemweb @rgggn @apconf oh shit, so there it no way to fix this I don't think other then reuploading them, that sucks

@liaizon No, the current state is fine. The issue appears when instances have already fetched them earlier and have them cached.
See toot.matereal.eu/@schmittlauch for a workaround @sl007 @Gargron @mlemweb @rgggn @apconf

@schmittlauch @liaizon @sl007 @mlemweb @rgggn @apconf Wakest is right though the only reliable way to make them public on all places that might have them cached is re-posting them.

@Gargron @schmittlauch @liaizon @mlemweb @rgggn @apconf

Yes, this is what I told @cwebber but we decided not "to stress" it.
What is the "public opinion" about reuploading?

@sl007 @liaizon @mlemweb @rgggn @apconf @cwebber

downside of republication: All links to the video (post-id) in posts her or on :birdsite: will break unless there are any redirects. But this will only become worse over time.

upside of republication: AP interaction, especially commenting, is an important part of this remote-federated . Only comments under the talk are discoverable.

My 2 cents: nuke it and republish 😥

@sl007 @liaizon @mlemweb @rgggn @apconf @cwebber Idea: It is possible to replace the video content, isn't it? Because then I'd advocate for re-upload but with replacing the old videos with a short placeholder and putting the new links into the description.

@schmittlauch @sl007 @liaizon @mlemweb @rgggn @apconf I think many sites have been fixed now, and let's please not re-upload... these talks have been linked to from a lot of places, and many presenters (including myself) would be disappointed if the original links weren't the right ones anymore!

@schmittlauch @sl007 @liaizon @mlemweb @rgggn @apconf But I think the situation is better now anyway so really, let's not stress over it :)

@cwebber

The question with reupload was _before_ the workaround was found, I think it is fine as it is now.

@sl007 I'm against it. Especially the Spiritly Talk and the Talk about the isolation of Gab reached far beyond the conference audience!
Probably just unlist them and reupload them public? (ah and note it in the video description?) Than links won't break and all instances will federate.
@Gargron @schmittlauch @liaizon @mlemweb @rgggn @apconf @cwebber

@Gargron @liaizon @sl007 @mlemweb @rgggn @apconf Meh.
The exact circumstancesof this incident need to be figured out and then discussed between Peertube and Mastodon devs – details like what setting causes which AP visibility and whether that's a good idea.

@schmittlauch @sl007 @mlemweb @rgggn @apconf

@Gargron can you delete the cache for mastodon.social specifically for conf.tube? would that work? since its probably the biggest instance that is currently messed up like this

@mewmew @apconf @rgggn @sl007 @mlemweb @liaizon @schmittlauch From Rails console:

Account.find_remote('apconf', 'conf.tube').statuses.where(visibility: :direct).each { |s| RemoveStatusService.new.call(s) }

@Gargron @mewmew @apconf @rgggn @sl007 @mlemweb @schmittlauch

@mastohost would you possibly be able to run this for all instances you host?! that would probably solve 70 percent of the remaining issues!

@mastohost @liaizon @gargron @mewmew@blob.cat @apconf @rgggn @sl007 @schmittlauch

I can't contribute anything to debugging, thank you all for your work on that. I agree with @eest9 that we shouldn't delete and re-upload, the videos have been shared too many times to go back and fix all of the links.

I propose that we update the descriptions on conf.tube with links to the SocialHub topics for each talk, and between that, the instances that have been fixed on mastodon, & #apconf2020 we'll be fine

@nicksellen Not sure if you are on tech duties for the instance instance.

Not a huge deal, but there was an issue with @apconf videos, thread here mastodon.social/@mastohost/104

Anyhow if someone could run the command @ Gargron mentioned above, it would allow the APConf videos to appear in our timeline. Thx

@nicksellen Not sure if you are on tech duties for the instance this week.

Not a huge deal, but there was an issue with @ apconf@conf.tube videos, thread here mastodon.social/@mastohost/104

Anyhow if someone could run the command @ Gargron mentioned above, it would allow ALL the APConf videos to appear in our timeline. Thx

@mewmew moderation interface -> accounts -> search for @.apconf@conf.tube user (without the dot) -> ban it -> unban it

@liaizon @sl007 @mlemweb @Gargron
Unfortunately it's likely not the only instance affected, and we cannot rely on every instance admin doing this.
It appears that this issue wasn't only present several days ago, but also just some hours ago – at least I do not know why my single-user instance should've tried fetching the keynote earlier than this evening where I manually triggered the fetch.

@schmittlauch @sl007 @mlemweb @Gargron I think it only affected instances that would already be following @apconf (which I was already doing since last year)

@liaizon @sl007 @mlemweb @Gargron @apconf Ah, I did that as well. That could've been how it happened.
But why should a "direct" post have been delivered to instances that are not allowed to see it? Sounds like a bug.

@schmittlauch @liaizon @sl007 @mlemweb @Gargron @apconf Accepting a "direct" post without your users being addressed also sounds like a nasty bug.

@lanodan @apconf @Gargron @sl007 @mlemweb @liaizon While "accepting" and caching it isn't nice, actually sending it to instances having nothing to do with the directly addressed actor even sounds like a privacy leak!
So both sides need to investigate that.

@lanodan @apconf @Gargron @mlemweb @liaizon

Hm,
in no way meant political, bu t about
"be conservative in what you do [send over a protocol] but liberal in what you accept" :

So I wonder why peertube does federate it at all.
I would not expect that as it says "unlisted, only visible to people knowing the link" …

But I agree that "both sides need to investigate that." @schmittlauch

@sl007 @apconf @Gargron @mlemweb @liaizon @schmittlauch Sure but accepting activities/objects that the instance cannot really use anyway doesn't seems like a good idea (would just be taking place in the database with little to no one being aware of their existence) and in this special case it didn't help.

@schmittlauch @liaizon @mlemweb @Gargron @apconf

For mastodon.social it seems to be solved now.
Again thank you.

/note to me: Good Morning America, see the power of communicating and coming together.

Now let us solve all remaining interoperability issues at the conf :)

@schmittlauch @sl007 @mlemweb @Gargron it must be how peertube is doing "unlisted" cause if you are already following it from mastodon it "sees" the new post and then sees that it can not fetch it and remembers that

@schmittlauch

Yeah, a bit weird, sorry.

This is a privacy concern indeed or it needs to be made clear to the enduser with other captions and better labels!

@schmittlauch @liaizon @sl007 @mlemweb @Gargron

Unlisted videos do federate by default - my understanding is that this is to be able to benefit from bandwidth offload? I didn't see a concrete use case for this, though.

However, as of v 2.3.0, there's an instance-level preference (federation.videos.federate_unlisted) that allows admins to prevent unlisted videos on their instance from federating, which is why the linked issue was closed.

cc @Chocobozzz

@schmittlauch @sl007 @Gargron @mlemweb @rgggn @apconf

how is the current state fine? only three of them can be commented on by anyone with a mastodon.social account

@liaizon

It is fine in the sense that it is already public addressed and that also just deleting the instances cache might work.

@Gargron @schmittlauch @rgggn @sl007 How does it evens do it? It doesn’t makes sense regarding it’s addressing:

"to": ["https://www.w3.org/ns/activitystreams#Public"], "cc": ["https://conf.tube/accounts/apconf/followers"],

@Gargron @rgggn @sl007 @mlemweb Workaround for instance admins: Temporarily ban the user @.apconf@conf.tube, causing the post objects to be deleted, then unban it.
Would be nice to know what caused that issue in the first place though to prevent it from reoccuring.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!