Hacker News Reader

Yes, the Fediverse isn't federated enough. Framatube is one of the organizations behind PeerTube. But PeerTube isn't very federated. It's just offloaded onto viewing clients. I think.

Here's a video of mine supposedly on PeerTube:

https://video.hardlimit.com/w/peBesyAgtzfRWS5FnDQQtn

Well, it's really on Hardlimit, which just outsources some of the playback bandwidth. I can't, as far as I know, play that without going to Hardlimit's web site. I can't even embed it without getting Hardlimit's branding. (Getting to full screen mode on mobile is really hard because their top and bottom banners get in the way of the video controls.) I ought to be able to put that long random key into other PeerTube sites and play it, but that does not seem to be possible. This is not "federation". It's a walled garden with outsourcing.

The video plays fine. I'm now using PeerTube for my technical videos, where I need streaming but the audience is people who find out about it on technical sites.

The federated video crowd needs to 1) get their act together, and 2) get some major forum systems to recognize their URLs as embedded video, as those systems do for Youtube, Twitter, and often Vimeo. That would at least bring them up to where Gyazo is.

The video is a pitch deck. A good one. But it's a pitch deck for something that's not fully usable yet.

You are very misinformed. Here is your video on a random instance I found in the instance list [1]: https://peertube.ignifi.me/w/peBesyAgtzfRWS5FnDQQtn

[1]: https://joinpeertube.org/instances

Did you try that URL? When I go there it says it's not available and directs me to the source URL.

"This video is not available on this instance. Do you want to be redirected on the origin instance: https://video.hardlimit.com..."

It works if you're logged in. There's no real reason you would want to watch a video on an instance that is neither yours nor the author's.

(too late to edit) Actually this works with other videos so I probably just stumbled on an instance that disabled this. There are plenty for remote videos on framatube.org, for example: https://framatube.org/videos/trending

Except in situations exactly like this one. A user shouldn't have to worry about local vs remote videos if they want to share the link outside the fediverse and someone clicking that link definitely shouldn't have to know about instances, federation, etc to be able to watch the video. Clicking the link should take them to a watchable video; if for some reason, it's not available for watching on the instance, it should use a http redirect instead of loading an intermediary page

Are you logged into those other peertube sites?

Most AP implementations that reshared all known content quickly discovered they were hosting stuff that made other people mad, and then those other people made lots of noise, because they couldn't tell the difference between rehosting and originating.

   #!/bin/sh
   PEERTUBE_INSTANCE="${PEERTUBE_INSTANCE-$1}";
   PEERTUBE_QUALITY=1080;
   test "$PEERTUBE_INSTANCE"||exec echo -e "PEERTUBE_INSTANCE is unset\nusage: echo shortUUID|$0 [PEERTUBE_INSTANCE]"
   test $PEERTUBE_QUALITY||export PEERTUBE_QUALITY=720;
   read x y;
   test ${#x} -eq 22||exec echo invalid shortUUID;
   z=$(curl -s "https://$PEERTUBE_INSTANCE/api/v1/videos/$x"|tr '\42' '\12' \
   |sed -n "/hls\/videos.*$PEERTUBE_QUALITY-fragmented.mp4/p"); 
   curl -4o $x.mp4 "$z";

Download video from PeerTube from command line

On mobile, an app like NewPipe will also work

usage

   export PEERTUBE_INSTANCE=video.hardlimit.com
   echo peBesyAgtzfRWS5FnDQQtn|$0

or

   echo peBesyAgtzfRWS5FnDQQtn|$0 peertube.ignifi.me

The JSON also includes torrent URLs and magnet URIs.

The C2S part of ActivityPub is, to put it mildly, cumbersome. It also shifts way too much logic to the client and prevents an efficient database design.

There can, theoretically, be a "dumb" AP server that implements both S2S and C2S and expects the client to do all the heavy lifting. In practice, all current ActivityPub servers are "smart". They treat the S2S protocol as more of an API, and have their own web UI with a specific user experience (Mastodon, Pleroma, and Misskey are microblogs, PeerTube is a video platform, Lemmy is a link aggregator, Smithereen is a social network, and so on). Interactions between these different experiences generally work on a best-effort basis. You can't shove Reddit into Twitter UX and expect something nice to come out, no matter how hard you try.

I'm not recommending that all server-side logic be inside of that single ActivityPub server.

What I would like is to run a "dumb" ActivityPub server that would hold all my activity and federate, by receiving and sending arbitrary JSONLD documents. This would be my only identity. Then, other servers like PeerTube, Gitea, etc can talk to that server for their federating needs.

When I stumble on a video post on Mastodon, I would have a link to open it in my PeerTube instance, where peer-to-peer video transmission would be implemented; but whether I retweet or reply from Mastodon or PeerTube, the same identity would be used. When I stumble on a merge request on Lemmy, I would have a link to open it in my Gitea instance, where Git repositories would be supported; but whether I upvote it from Lemmy or approve it from Gitea, the same identity would be used.

This would fit the narrative of the video.

> Imagine if you could share videos, events, instant messages, microblogs with the whole universe. Imagine if it didn't matter which planet you came from.

> Your login on any of those services allows you to interact with a whole diverse universe.

> You can't shove Reddit into Twitter UX and expect something nice to come out, no matter how hard you try.

Why not? it's text; you could make the same exact post on reddit and twitter (barring the length, which could be truncated in a federated context). Link aggregation is basically just microblogging with the extra constraint that the initial post has to have a link.

> Smithereen is a social network

What does this mean? Every other platform you mentioned are social networks. On all of these platforms, a user posts text or media posts. Displaying them in a different UI doesn't make them radically different.

> Why not? it's text;

The UX is important. It's important that all users have the same one. For link aggregators, you want comments displayed as a tree. For microblogging, flat lists work better, especially when people post "threads", which they do.

> What does this mean? Every other platform you mentioned are social networks.

I meant a Facebook-style social network.

> The UX is important. It's important that all users have the same one. For link aggregators, you want comments displayed as a tree. For microblogging, flat lists work better, especially when people post "threads", which they do.

That's subjective and exactly the type of thing that could be handled in a client. In both cases you're displaying the exact same data. A microblogging thread may be displayed as a flat list, but it's still a tree like a link aggregator thread.

> I meant a Facebook-style social network. So a platform to post what are essentially blog posts. In ActivityPub, that would be the Article type, which, according to the spec, has no semantic difference from Note. An Article could be created as a Note and vice versa with no semantic difference or loss of data. Just like above, the data is the same and the only distinction is the visual presentation of it.

> That's subjective and exactly the type of thing that could be handled in a client.

There needs to be a web UI of some sort. You need to be able to send people links to things that they can open in their browser with nothing extra installed. It's a hard requirement. You can't require the use of a client app.

Right, but that doesn't mean the server can't support other post types or leave complex UI to other clients. Each server could fallback to displaying a link to an external post at a bare minimum, or display whatever the `content` field. I'm just arguing that the C2S is perfectly viable and would make the fediverse so much richer and more usable. Using the Masto API to federate only specific types with specific software is limiting the fediverse.

Not sure what you mean. I'm on Friendica, and I can follow, reshare and comment on posts from people on other platforms with no problem. I don't need accounts on other servers for this, though I'm sure my interaction with them is limited to whatever Friendica supports. I don't doubt you can do more if you actually get accounts on different systems, but that's a choice you have. I don't think you need to do it if you don't want to.

Follow and comment are the only things that are supported across platforms. That is what I mean by "exchanging at a basic level". To use any of the various features that makes the various applications worthwhile, you have to go create an account in that application and subscribe to people's accounts from there.

When Gitea implements federated merge requests and tickets, you will be able to follow repositories from Mastodon and comment on issues from there. That's great! But to do anything else (create/assign/close issues, open/review merge requests, ...) you will have to create a separate Gitea account and use it to interact with Gitea users. This is a serious limit to "interacting with a whole diverse universe".

But you can't post a video to Peertube or start a thread on Lemmy. There's a level of interoperability that was envisioned for the fediverse that we're missing right now. If you post a video, Peertube users won't see it despite being the fediverse's main video software. If you post a link with your commentary, Lemmy users won't see it despite being link sharing software.

The microblogging platforms ingest most types of posts from the other activitypub softwares, but the other platforms don't ingest posts from the (micro)blogging platforms. With the client-to-server API, the other platforms would just be clients on top of your Friendica account.

> I am not sure why the ecosystem went this way

Because when activitypub was still getting off the ground, mastodon built their own client api. A lot of excited people built apps for mastodon so pleroma, and then others, started building Masto API support so that their instances could use mastodon clients. Now the Masto API is the de facto client api.

I super agree with you, using the client-to-server protocol so that we could have one account would be the best situation. I've been arguing that on the fediverse for a while, but all the developers in the space seem to think the client-to-server protocol isn't useful enough so you would have to fallback to a custom API for the missing pieces anyway so you might as well use the API everyone's already using.

this is why i gave up on mastadon. add that to a non-existent on-boarding experience.