596 karma · joined July 30, 2012
Sadly limiting instances like mastodon can do isn't available in lemmy or kbin afaik, so highly moderated instances like beehaw are resorting to complete disconnection (defederation) for now until moderation tooling improves.
One caveat about the current implementations is that a defederated instance doesn't seem to know it's been defederated from, so a stale copy of the remote content still exists and can be interacted with (users can post in the remote community that defederated and comment on stale posts, or even new posts in the remote community that are made by local users, however none of that will get synced to the remote communities / instance that defederated).
* Opening comments regularly takes 30-45 seconds, I sometimes think I mistapped, and end up with 2 post comments activities overlaid on top of each other
* Comments often open the wrong post comments
* Opening comments on a video post sometimes opens a non-loading video player with missing comments button, have to repeatedly re-open or try sharing the link to desktop in order to get to comments (assuming the next bug doesn't lose the post for you)
* Backing out of comments has a significant chance of returning you to the top of the feed instead of where you left off
* App just straight up crashes out of nowhere
* Autoplay settings don't seem to be reliable
* Another huge peeve of mine is due to the shared "video mute" setting in the video player, if you play a video with audio, the mute control may fade out and not return, requiring you to scroll to a different video, deal with the autoplay audio, and then hope you can use that video's mute button to get your feed muted again. This is especially annoying when the feed gets unmuted and I come across a video ad
I'm surprised by how many people say they use the official app without any issues, from my perspective it seems chock full of bugs, race conditions, and overall bad code. I don't know how people are managing to avoid these bugs.
The neat thing is that it unzips the file locally and only uploads the posts you select, which Dansup says helped get around very large instagram archives and also means you don't have to worry about posts you don't want imported being sent to the pixelfed server.
facebook.com##div[data-pagelet*="FeedUnit"]:has(div[aria-label="Sponsored"])
facebook.com##div[data-pagelet*="FeedUnit"]:has(span[aria-label="Sponsored"])
facebook.com##div[data-pagelet*="FeedUnit"]:has(a[aria-label="Sponsored"])
facebook.com##div[data-pagelet*="FeedUnit"]:has-text(Suggested for You)I've wondered how send could be so slow but maybe something in my setup is just killing it. More than anything though, I would love an easy way to access my phone's sharing options from my laptop (perhaps an addon button that shows a list of app intents that can receive a url/page).
This is one thing I'm hoping to hack at when I get my Librem.
I assumed "got" was extraneous due to editing, removing it sounds a lot better to my ear: "An alternative architecture would be to have Gitter directly federating with Matrix by..."
I assumed it was a mistake due to editing, since I would use "got" primarily in this way: "An alternative architecture would be if we got Gitter directly federating with Matrix by...", to my ear "got" normally follows a noun, but I think the alliteration makes it sound extra awkward.
At any rate, I'm no english major so it's not a big deal.
> You can already create non-repo rooms in Gitter
My question is less about non-repo rooms and more about rooms that look like repo-rooms. Is there any protection against a malicious user setting up "#google_chromium:gitter.im" and distributing malicious binaries?
Edit: Maybe I'm not really asking a clear question - overall I'm wondering what the long term plan is for the gitter room addresses, where you can be sure that matrix-org/matthew-test belongs to matrix-org. It seems to me that if the gitter room addresses are planned to be removed in the long term, the security implications of the room address will change, so I was looking for some mention of that in the post. Not that it's a huge deal if communicated properly, people would just have to be sure they found the room from an official repo and keep in mind that the restriction of creating rooms under the org is no longer present.
Also, I'm curious what the plan is to reconcile Gitter's one room per repo model with Matrix's anybody-can-create-any-room - in the long term, is the plan to keep gitter.im rooms restricted to matching repos? Or (post gitter-skinned-element) will people eventually be able to create arbitrary rooms on the gitter homeserver?
Because of these 2 "features", when I clone dmca and run `git pull some_ytdl_git_mirror master --allow-unrelated-histories`, I end up with a giant source tree that consists of both repos joined by a merge commit. Because no rebasing happened, no history was changed and it can be pushed without force permissions. Now that all the youtube-dl commits are in the same tree as the dmca repo, you can access them regardless of what fork you've cloned via `git fetch origin <hash>`.
I hope that makes sense?