Goofed Home

So, I’ve uploaded some videos on peertube.wtf and I can’t see how large each one is, nor can I sort them. I want to be able to delete large videos if I run out of total quota. This is on version 8.0.1

https://lemmy.fedioasis.cc/pictrs/image/6ed87615-2f91-41d1-9fa9-d89666bec454.webp

I do think a video quota is a good idea, and PeerTube has two quotas, your daily limit, and total limit.

https://lemmy.fedioasis.cc/pictrs/image/7b1fe8e4-522d-4121-aa8f-3363524b0271.webp

The total limit will fill up eventually if the account is active, and I think a way to see the largest videos you have on your account would help a ton.

This is my first PeerTube experience, the site is slow when browsing content, but it works. Peertube.wtf is federated with over 1,531 other platforms, so content is coming from a wide range of places.

https://lemmy.fedioasis.cc/pictrs/image/e51d5e15-c135-4165-a793-25f8af5bfc8e.webp

The quota given is quite generous, You get a daily upload limit of 10GB and a total limit of 100GB. For someone’s computer space, that’s quite generous.

One thing I don’t like is that the subscriptions feed takes like 30 seconds to load before telling me I have no subscriptions.

You can get a rough idea of how big each video is via an activitypub query for each video. For example:

curl --header 'accept: application/activity+json' https://peertube.wtf/w/mhghLtY5dkLguNq5oFB2Ut | jq .

Buried in there is a url entry, and buried in some of those is a tag entry and buried in some of those are details for the size of the video and audio for each upload.

Peertube’s video channels have an outbox (similar to how Lemmy’s communities do, but not limited to 50 entries), so you can step through that to find the relevant info for everything in your channel.

Doing that for your channel, I got:

Shitpost #2
video: 482 x 480: 2.27 MB
audio: 0.3 MB

Shitpost #1
video: 480 x 480: 8.69 MB
audio: 0.94 MB

Will this replace the internet?
video: 1080 x 1920: 19.26 MB
video: 720 x 1280: 11.9 MB
video: 360 x 640: 5.23 MB
audio: 16.75 MB

Cat
video: 1920 x 1080: 7.77 MB
video: 1280 x 720: 2.14 MB
video: 640 x 360: 0.41 MB
audio: 0.23 MB

If you assume that the size of the audio is ignored, and that lower resolutions are transcoded as requested, and add the sizes for the highest resolutions together, you get 2.27 + 8.69 + 19.26 + 7.77 = 37.99 (which is the 38 MB visible in your screenshot).

The information is available, but it’s a pain in the arse to get, so it’s probably annoying for PeerTube themselves to show (a brief look suggests that the API response doesn’t provide it, so there’s nothing for the web frontend to display). It’s also possible that they may drop the higher resolutions for videos with low engagement, so the size of each upload isn’t static, which adds an extra complication.

cross-posted from: https://community.nodebb.org/post/106679

Hello all!

(Sorry, I could not resist with the title :laughing:)

Today we are releasing NodeBB v4.9.0, on a Friday, toward the end of the day, because we like having our weekends ruined.

As usual, we recommend you update to this stable version of NodeBB, not least because it fixes a federation issue accidentally introduced last month.

There are a bunch of new features and usability improvements here, for both end users and admins. Federation improvements abound, as well as a few moderation upgrades. As usual, we fixed a ton of bugs, and even a couple open issues from the 2010s :scream:

Here is a list of the changes and new features you should expect to see!

:world_map: New “World” page

/world has been updated so that is closer to a feed-reader than a topic list. While I will continue to iterate on this design over time to better promote topics, I am hoping that this proves to be more accessible of an interface compared to the old topic listing.

Your watched/tracked remote categories will be listed in a sidebar (hidden behind a drawer on mobile views) for easy access.

The default view (“Latest”) continues to be a list of content from people you follow, and content shared by those same people. The other view (“Popular”) shows unconstrained content, and can include content from people you don’t follow.

:lock: Remote topics now unavailable to guests

After an Alibaba bot was recorded mercilessly scraping a lot of the public content served up by NodeBB, we decided to restrict access to that content to registered users.

While this would normally mean that “View Original URL” would stop working from other federates sites (since visitors are usually guests), we have added an exclusion to this logic that will continue to serve up the content to guests if at least one local user has commented on the topic.

:writing_hand: UX change for composer and chats

@baris worked on a number of usability fixes that make the experience of using our post composer and chat interface much better. For the longest time we had issues with the composer not properly resizing when mobile keyboards opened.

Composing and replying should work much better now that we are using the latest CSS and javascript tooling to properly detect visual viewport changes.

:bell: Better notifications

@baris also updated the notifications system so that bodyLong, which usually contains post text, is now sent with all notifications. This should increase the usability of notifications (both via web, email, or push).

:arrows_counterclockwise: Cross-posting privilege

A previous release introduced the ability to cross-post content into local categories. This functionality can now be gated behind a privilege at the category level.

:wave: Guest call-to-action

@baris introduced a new guest “call-to-action” banner that will help guide guests toward registering a new account to contribute to your community :blush:

:label: Title-less topics

As part of the changes to /world, we also allow the creation of topics without a title. If you don’t pass in a title, we will generate one for you based on the first sentence in your post. The same title generation logic was applied to remote content in the past, and now it also applies to local content.

This also means you can use the /world page to just fire off something quickly without having to do the hard work of thinking up a title. You’re welcome :laughing:

:sparkles: Opportunistic backfill

Now that the fediverse’s largest implementor, Mastodon, supports context, which enables backfill, we have implemented an opportunistic backfill feature that will check for new replies when you enter a topic. It’ll also regularly check the top most popular remote topics known by the instance for new posts.

:no_entry: Reasons

You can now set up a recurring list of “reasons”, which you can invoke on certain moderation actions. These custom reasons can be used when a user is banned, muted, or on post queue rejection.

You can set up these reasons from ACP > Manage > Users > (Gear) > Manage Custom Reasons

image (2).png

:information_desk_person: Registration queue now applies for SSO plugins

This issue, open since 2016 is finally fixed. SSO plugins don’t automatically bypass the registration queue anymore. This was a common vector for spammers to bypass registration limitations.

:bug: Additional features and bug fixes

• An improvement to auto-installation of plugins
• Removed many remote tids and pids stored in the db for no reason (thanks @baris)
• A regression that caused nodebb-to-nodebb federation to fail (and possibly many others)
• Notifications can now be passed custom icons
• ACP privilege selector now no longer shows remote categories
• Improvements to mentions to better handle periods at end of sentences, or names within names
• All cached used internally are now exposed in the admin panel for better management.
• Sitemap cache duration is now configurable
• Infinite scrolling now works on /world
• Slug generation errors when you mixed and matched - and .
• Topic pruning applies to all remote cids now, not just cid -1
• Chats list updated properly now, when new messages are received, chat messages now properly backfilled upon reconnection
• NodeBB now federates Delete on both deletion and purge

---

For the full changelog, please take a look at the closed issues list for this milestone, or take a gander at the much less impressive CHANGELOG.md in our repository root.

On .zip I do see a post in there. I’ll join and see if something pops up

Ahh I bet that means it’s an issue between Piefed and Nodebb then. I’ll check their repo and see if it’s a known thing

As it stands right now, it looks like we have to just judge based off of how old posts are to see if we can still interact with a community.

Yep.

it doesn’t save my settings or my favorites and multi-communities.

It should save/persist the favorites to your browser’s local storage. If you’re using a browser that clears site data on close or something, then they’ll reset. But it also wouldn’t persist your profile and you’d have to log in every time, so….🤔 It doesn’t, however, save any settings beyond your device. I’m working on a way to securely save those to whatever Tesseract server you use but don’t have it implemented yet.

This version (1.4.42) also changes where and how the favorites, community groups, and filters are stored in addition to not storing useless data like the community sidebar info, etc. They’re also no longer stored inside your profile in a single local storage object. Since these save to the browser’s local storage, there’s a hard 5 MB limit per object (everything gets written to a JSON string), so maybe your profile exceeded that somehow? If so, there should be browser console logs to that effect. Regardless, this version splits those all up into separate storage objects to address that problem.

Not sure what you mean by multi-communities, though. There was a feature to create custom feeds (which is kind-of similar to multi-community) but I took that out a long time ago because API changes in 0.19.3+ made it untenable. I think that was removed in 1.4.40 or thereabouts, so if you’re on a version older than that, then maybe that feature is still present. That feature was pretty broken for a long time which is why I finally removed it and put it out of its misery.

It doesn’t, however, save any settings beyond your device. I’m working on a way to securely save those to whatever Tesseract server you use but don’t have it implemented yet.

Thank you for explaining that. I clear the cache quite often. I haven’t tried to save the favorites in a bit because I thought it was tied to the settings. Changing the settings each time isn’t a big deal, but saving favs kind of is. I’ll give it another try since it’s pretty great.

About AIPAC:

The American Israel Public Affairs Committee is a tax-exempt 501©(4) non-profit group that lobbies for strong U.S.-Israel relations and pro-Israel policies.

About Track AIPAC:

Track AIPAC is a grassroots effort to reveal and counter the influence of AIPAC and the Israel lobby by systematically documenting their financial contributions to our federal officials. We support candidates who refuse support from the Israel lobby and champion a foreign policy based on human rights and international law.

cross-posted from: https://lemmy.ca/post/61027702

Trump’s Truth Social is based on Mastodon (even if with federation and syndication disabled), and the POTUS Threads profile iirc has ActivityPub enabled. Also wasn’t Germany that also adopted for some government profiles fediverse-compatible services? Or some other EU country. Still, if the neighbors and ideological allies of Canada already tapped into such projects, I’d say it’s no longer uncharted territory.

Also wasn’t Germany that also adopted for some government profiles fediverse-compatible services?

The German Goverment has a Mastodon instance:

https://social.bund.de/

It’s now way prettier and contains almost 1300 accounts.

You can show/hide columns, there is a powerful custom search and a button to download an CSV with the handles of all visible accounts for import. There’s also the language, the country of origin, and a direct link.

I also noticed that, maybe it would help to add some kind of loading progress indicator?

Yeah, I’ll try

Most major platforms still rely on a very old identity model: one username, tied to one email, tied to one permanent account. Once something goes wrong — lost email, deleted account, forgotten recovery info — the identity is gone forever, even if the user wants to return.

Examples many people run into:

Deleted Reddit accounts permanently lock the username, even if the user returns years later.

Facebook accounts can’t be recreated once deleted, and recovery depends entirely on old email/phone access.

Steam accounts are tied to payment methods or emails people may no longer have.

Many services keep usernames in a permanent record even after deletion.

This creates a strange kind of digital permanence: you can delete an account, but you can’t delete the identity attached to it.

So I’m wondering:

Could online identity work without permanent usernames at all?

Could identity be modular or replaceable instead of tied to a single handle?

Would hardware keys, biometrics, or wallet‑stored codes solve the “lost email = lost account forever” problem?

Why do so many platforms treat usernames as permanent even after deletion?

Is this a technical limitation, a policy choice, or just legacy design?

Could federated systems eventually support more flexible identity models?

I’m curious how others think online identity should work, especially in a world where people change emails, lose access, or want to return to a platform without being locked out of their own name forever.

At its heart, identity is about uniqueness. Being able to tell that things are distinguishable from each other. The real question to answer here is, how is uniqueness determined? What can anything or anyone use to be certain that they are recording against something unique? Most systems implement a UUID internally which they can guarantee is unique per entity in their system because they are the issuer of the identity. However, giving these unique identifiers out to other systems is problematic for exactly the reasons you mention. If lost, forgotten, or stolen, the original entity can no longer get them back.

For digital systems and man made things, uniqueness is relatively straightforward. Unique ID identifies the thing is who they claim, but for people this quickly gets difficult.

How does a person assert with authority they are a specific someone? What can be reliably used? The likeliest pathway is biological factors, such as DNA, but identical twins share DNA, as do cloned things. Fingerprints are unique, assuming you have them, and if you don’t, also not reliable. Biometric data is often used but not 100% reliable. Failing that the next best identifiers are things issued by other authorities that your system is willing to trust. You might want to use a government issued document, from a reputable government, that can be verified, and is hard to forge. Not foolproof, but good enough. We rely on the government not to issue that same ID to two different individuals, and we rely on the individual retaining their government ID over long periods of time. Unfortunately, government IDs are not commonly used due to the high-risk nature of the data on them, and the low frequency of users having them handy. America tries to issue an ID to all users for this type of reason, the Social Security Number, but these have become extremely flawed over years due to data breaches and the fact they are passed around so freely that anyone could know yours.

Failing that, systems look for something else they can use that is globally unique, and stays with the user. Phone numbers aren’t adequate as they are often recycled and change frequently. The closest thing available, as you’ve already pointed out, is the email address. By necessity, emails are globally unique. We rely on them not being recycled too often, and they are most commonly (although not always) associated with an individual. Systems rely on the issuing authority to not break the system by issuing one to more than one person, and it serves a dual purpose of being able to be used to contact the owner.

No matter what system is put in place, there is a reliance on some authority maintaining and managing the integrity of the identifiers. Decentralised identity still relies on a person having access to the ID, and if that person loses it, then it’s between them and the identity provider to work out how they get it back, for the consuming applications, the same practical issues exist. A lost or changed ID results in a new entity on the application and the old one becoming unusable.

Most applications have workarounds for people losing or changing their identifiers (such as email address) but often this relies on the user changing it whilst still in passion of the old one, or relies on another method of verifying the person is who they claim, such as government identifiers, assuming they have at some point captured that information in the first place.

That’s a very important question we need to address !

It makes sense for platforms to block reuse of identifiers: they identify something, if the thing changes it should get a new identity.

Identities are fundamentally that: how to recognize that something is not something else. Note that it really is something: the same person can have multiple identities, and an identity can be shared by multiple persons.

The main issue is that we have been immersed inside a State-based system for so long we forget it exists. The first thing that comes to mind when we talk about identities is our state-delivered identity: name, surname, address, driving license number, etc… there’s a central all-powerful authority deciding what identity is given to whom, and they are unique and active as long as the State decides. In practice this has made identities a public-facing concern because the State is in charge of everything.

Centralized platforms, of course, reproduce the model. Both the State and capitalist platforms (or capitalist anything) act under the paradigm of total domination, there’s no surprise here: the platform owns your identity, your data, your you. When we reproduce the same thinking in open/decentralized platforms we inherit the mentality although everything points to not actually wanting it: we don’t want a platform to have control over our identity/identities unless we have control over the platform, yet in practice we do. We link an identity with a name, so of course names must be unique

We need to go back to the roots: what is an identity ? A way to differentiate two things to someone. Who can guarantee the identities we have ? Our connections. “Mom” is an identity in my contacts app; this identity is obvously not the same identity as “Mom” in your contacts app, although the name is the same. That’s because this identity is not the same to me that it is to you. The entity “using” the identity is fundamental. That’s something we forget when using centralized platforms: the entity “using” my identity isn’t my contacts, it’s the platform. To the platform, everyone must be unique, so must have a different name in their “contacts app”. That is not a model that cares about us but about itself.

What model cares about us ? A model that puts the focus back not on the individuals being represented, but on the relationship. An identity can never be defined by biometrics or hardware keys or whatever technic that technosolutionnist rave about. Technosolutionnists by definition do not care about sociology, so they shouldn’t be listened to for sociology issues. An identity will always be defined by who recognizes you as such.

What does it mean in practice ? Basically, we need to build communities of people taking care of each other. My access to the group chat shouldn’t be defined by a technical solution to access the app; if I lose access to the technical solution, the community still knows my identity as the same, so it must be able to re-integrate me without a hurdle, whatever the technical means.

What this means is that identities shouldn’t be public-facing. They should be something inside a community only, defined by it with the means it decides.

Note:

• this is related to the fallout and backtracking from Discord’s age verification changes
• I haven’t confirmed what license this is being released under

Despite the issues with the companies involved, maybe there is something here that Fediverse platforms can benefit from. Whether it is using the tools directly, or using it for ideas when building something better.

From the site:

Coop provides content review tools and includes the ability to route reviews to the experts, show relevant information for a comprehensive review, and take action. The platform includes built-in integration with the National Center for Missing & Exploited Children’s (NCMEC) API for mandatory reporting of child sexual abuse material (CSAM), ensuring compliance with relevant regulations.

Osprey is an open-source investigation and incident response tool that allows safety teams to understand what is happening on their platforms and take actions at scale. Osprey’s lightweight, user-friendly design makes it especially valuable for platforms of all sizes, from grassroots communities to established platforms that need powerful tools without enterprise-scale infrastructure.

Bluesky is taking from it already:

“We’re excited for the implementation and release of Osprey,” said Aaron Rodericks, Head of Trust and Safety at Bluesky, which plans to adopt Osprey. “This represents exactly the kind of open collaboration needed to democratize safety tools. By implementing Osprey, we’re helping prove that effective safety infrastructure can work for platforms of all sizes, not just those with massive resources.”

Osprey, huh? Here’s a bird for you Discord. 🖕
In unrelated news, I learned about Sharkord today.

Important progress has been made regarding bringing MLS end-to-end encryption to the ActivityPub protocol, with developers already building implementations and providing feedback to a future version of the protocol spec.

nothing per se, depends on implementation

TLDR: an e2ee channel means “everything passing over this channel is super secure and private, but it needs some keys for this to work”. e2ee means something: you can not care about most issues with delivery and protection and such, but you need to care about the keys. if you don’t do that, you are probably ruining the security of such e2ee channel

end-to-end-encryption solves one issue: transport over untrusted middleware, doesn’t mean much by itself. it’s being flung around a lot because without proper understanding sounds secure and private.

it’s like saying that i ship you something valuable with a super strong and impenetrable safe. but what do i do with the key? e2ee is the safe, solves the “how can i send you something confidential when i dont trust those who deliver it”, and it means much! it’s a great way to do it.

but it solves one problem giving a new one: what to do with the key? this usually can be combined with other technologies, such as asymmetric encryption (e.g. RSA), which allows having keys which can be publicly shared without compromising anything. so i send you an impenetrable code-protected safe with an encrypted code attached, and only your privkey can decrypt the code since i used your pubkey!

(note: RSA is used for small data since encryption/decryption is cpu intensive. usually what happens is that you share an AES key encrypted with RSA, and the payload is encrypted using that AES key. AES is symmetric: one key encrypts and decrypts, but AES keys are small. another piece of technology attached to make this system work!)

but now comes the user-friendliness issue: very few are big enough nerds to handle their keys. hell, most folks don’t even want to handle their passwords! so services like matrix offer to hold your keys on the server, encrypted with another passphrase, so that you don’t need to bother doing that, just remember 2 passwords or do the emoji compare stuff. it’s meh: compromising the server could allow getting your keys and kinda spoils e2ee, but it’s convenient and reasonably secure.

what does whatsapp do? i don’t know! but it kind of magically works. if they do e2ee, where are the keys???? how does meta handle reports if messages are e2ee???????

also, e2ee works if you can trust the key you’re sending to! as mentioned in the ‘activitypub keys’ section before, if you ask a middleman the key for your recipient, can you trust that’s the real key? e2ee doesn’t cover that, it’s not in its scope

so what does e2ee mean? it means: super strong channel, ASSUMING keys are safe and trusted. e2ee as a technology doesn’t solve “all privacy” or guarantee that nobody snoops in per se. it offers a super safe channel protected by keys, and lets you handle those keys how you more see fit. which meaning deciding who you trust to send, how you let others know how to encrypt for you (aka share your pubkey) and how you will keep your privkey safe.