> your fears/worries about the “growth” may suddenly just hit us hard
I'm not afraid of the network growing, I'm actually very excited to see it grow. My concern was with keeping *my* real-life and online identities separate.
> your fears/worries about the “growth” may suddenly just hit us hard
I'm not afraid of the network growing, I'm actually very excited to see it grow. My concern was with keeping *my* real-life and online identities separate.
> your fears/worries about the “growth” may suddenly just hit us hard
I'm not afraid of the network growing, I'm actually very excited to see it grow. My concern was with keeping *my* real-life and online identities separate.
My concern from that thread was about mixing public and private identities because the network is still quite small.
Proprietary software claiming to “protect your privacy” cannot and should not be trusted.
> We plan to open source our Mac app after the beta period, like we’ve done for our iOS & Android app, and many of our built-in privacy protections are already open sourced.
https://spreadprivacy.com/introducing-duckduckgo-for-mac/
> why not? What is wrong about that browser?
It's proprietary and DuckDuckGo has had a sketchy past.
@prologic, I announced it in the beginning on my main feed but I haven't been announcing each individual post. I think I will from now on.
This will change when the network grows bigger and there's a larger anonymity set, for lack of a better term.
Like @lyse said, this is an extremely selfish reason, but it is my reason.
Coincidentally, my time table generator was the first useful thing I wrote in C.
Some things we talked about:
* Time zones and DST
* Mastodon and scalability
* E-mail and decentralization
* Twitter and Elon
* New twtxt feeds popping up since the bird was freed
Also, @prologic said he's not interested in ActivityPub integration for Yarn.social*
As for @prologic's feed, it's using the Archive Feeds extension to cut down on file size.
As for @prologic's feed, it's using the Archive Feeds extension to cut down on file size.
It would be midday here in the US, but I have the day off on Saturday. Not sure about @ocdtrekkie.
It would be midday here in the US, but I have the day off on Saturday. Not sure about @ocdtrekkie.
> Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 60,000 lines of code you were going to write anyway.
I agree; the lack of hackability in Wayland is very unfortunate.
> Unfortunately, the reasoning behind rel="self" remains a mystery.
I don't know where it would be useful, either. I have one in each of my Atom feeds for the same reason. It's a Chesterton's Fence situation for me. It's not doing any harm, and the W3C says it should be there, so I put it there.=
I'll use proper syntax from now on.
> I always want my URL also to be my ID, so I have to duplicate that – unnecessarily in my opinion.
Interesting. I understand what you're saying, but I find the duplicated functionality of the RSS
<guid> to be confusing. I think it would make more sense if the roles were reversed: use the <link> as the ID if there's no <guid> and never use the <guid> as a permalink. Bonus points if a <guid> is required if a <link> is not present.Actually, when doing research for this post, I stumbled upon this blog post: How to make a good ID in Atom
I have no idea how I ended up at a blog post from 2004 that hasn't been online since 2011, but I did. Regardless, he has a point. I had never heard of tag URIs before. I think I'll start using them.
> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes][establishes=] the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
This is all it has to say on
rel="self":> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.=
> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes] the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
This is all it has to say on
rel="self":> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes][establishes][establishes][establishes][establishes][establishes][establishes][establishes] the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
This is all it has to say on
rel="self":> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it \n\n\n\n\n\n\n\n the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
This is all it has to say on
rel="self":> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes][establishes=][establishes][establishes=][establishes][establishes=][establishes][establishes=] the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
This is all it has to say on
rel="self":> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it \n\n\n\n the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
This is all it has to say on
rel="self":> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it [establishes]\n[establishes]\n[establishes]\n[establishes]\n the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
This is all it has to say on
rel="self":> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
> Any element defined by this specification MAY have an xml:base attribute...When xml:base is used in an Atom Document, it \n\n the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.
This is all it has to say on
rel="self":> The value "self" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.
> A new sidebar design in System Settings — instantly familiar to iPhone and iPad users — makes it easier than ever to navigate settings and configure your Mac.
Let me fix that.
> We moved all the settings because we're trying to make our desktop operating system as terrible as our mobile operating system. Good luck trying to find anything, cattle!
Alright, I promise I'm done now.
I skimmed through that page, and one thing stood out to me above everything else.
> Simply bring iPhone close to your Mac and it automatically switches to iPhone as the camera input. And it works wirelessly, so there’s nothing to plug in.
By default? That seems like extremely undesirable behavior.
Plex might be able to do this, but I'm not sure how much they insist on handling authentication on their servers.
cc @movq @lyse @nmke-de
It only took me 5 days :)
alias theo='shuf -n 1 ~/Documents/theo.txt'
echo "<theo> $(theo)"
I didn't make the list myself and I can't remember where I found it.
Who do you work for? Governments?
alias theo='shuf -n 1 ~/Documents/theo.txt'
echo "<theo> $(theo)"
[mckinley@t430 ~]$ theo
Your emails only contain opinions.
<theo> Come on guys. Don't have me OK this.
[mckinley@t430 ~]$
Spoiler: Atom is better.
After I update my feeds, I do a lot of manual filtering, marking videos I don't want to watch as read. This would stop the cache system from downloading or storing videos I don't want to watch.
> This program, that downloads all required videos found in Newsboat’s SQLite database and removes them once marked read, that would be a cronjob? No user interaction required, did I get this right?
It could definitely be a cron job, but I think I'd rather have it as a hotkey in my window manager. That way, I could run a video cache update after I'm done marking unwanted videos as read. Other than that, there would be no interaction required.
I'll bet it's nice to have an offline copy of your videos. I've been thinking about a program that interfaces with Newsboat's database directly, getting the URLs of all unread articles with a specific tag.
When it runs, it would queue new videos for download with yt-dlp and delete any videos in the cache directory that I've marked read in Newsboat. From there, I'd just need a wrapper script to look for the video in the local cache before letting MPV stream it.
I was working on a prototype of this system a few weeks ago, but my implementation was just too hacky and I got sidetracked.
Also, what program are you using for the syntax highlighting in the article? I've been thinking of doing that for my site.
If it's anything really long like a book, I'd prefer a printed copy.
* 2022-10-25: https://archive.ph/q7b4J
* 2022-10-29: https://archive.ph/RoFt2
I think Nitter is fine. It has a ton of public instances and a relatively active development community. The number of public instances show that there's a lot of demand.
The
Last-Modified header probably accounts for the time it took in between setting the timestamp in the Atom feed and pushing the changes to the Web server.@carsten, what's wrong with the RSS feed?
There's a repository feed at https://git.mills.io/yarnsocial/yarn.rss but it's even *more* broken.
@abucci Interesting. Can you tell us more?
However, this sort of malicious forced push can still cause a lot of damage, some of which can be very difficult to repair. It's better for archival purposes to make a full backup and then pull in the updates. A human can sort it out from there.
Today, I'm making it resilient against the maintainer force-pushing an empty branch in an attempt to foil archives. There's still some more work to do, but I just ran a successful test.
The complete history of the repository is backed up in the bundle before the evil maintainer's force push is brought in.
Output of my Git script when detecting a malicious forced push
It's back up now.
Gron has no such option. Apparently there is no reason why you *wouldn't* want a text processing program to make network requests.
1. Microdependencies
2. Feature creep because you can do *x* in 3 lines of code by adding this giant dependency. (Why does gron need HTTP download support?)
It wasn't difficult to go through the data by hand after it was filtered a bit.
There are 195 registered users, only a handful of which have specified a description or URL.
There are 203 non-fork repositories, but only 27 of them are owned by entities other than
prologic, yarnsocial, and saltyim. That prologic guy alone accounts for 152 of them.
jq so I went hunting for spam accounts on git.mills.io using data from the API. Here are the results. I thought I'd find more than 11.
1. It's creating the directory tree as it should, but the assets are incorrectly placed in the same directory as the document
2. The paths in the document should be rewritten to be relative instead of absolute
3. It respects robots.txt and there is no way to turn it off (I had to delete the file on my machine to make the tool work)
4.
<link rel="canonical"> isn't a page requisite, but the tool downloads the file at the specified URL anyway. (It doesn't respect robots.txt when doing this)https://ttm.sh/0Pb.txt demonstrates the problems with the directory tree.
$ curl https://raw.githubusercontent.com/answerdev/answer/main/go.mod | grep -c '^ '
84
$ curl https://raw.githubusercontent.com/answerdev/answer/main/ui/package.json | gron | grep -c '[Dd]ependencies[\[\.]'
76
No thanks...
$ curl https://raw.githubusercontent.com/answerdev/answer/main/go.mod | grep -c '^\t'
84
$ curl https://raw.githubusercontent.com/answerdev/answer/main/ui/package.json | gron | grep -c '[Dd]ependencies[\\[\\.]'
76
No thanks...
$ curl https://raw.githubusercontent.com/answerdev/answer/main/go.mod | grep '^\t' | wc -l
84
$ curl https://raw.githubusercontent.com/answerdev/answer/main/ui/package.json | gron | grep '[Dd]ependencies[\\[\\.]' | wc -l
76
No thanks...
> "Delete and Redirect"
That's a great idea.
> I honestly think the best way to handle this as we grow/scale with more pods in the Yarn.social network is to just build up a strong positive community and just have a “zero tolerance” attitude towards abuse and just nuke offending feeds/accounts without question.
I personally disagree with this moderation policy, but it's your right to enforce your rules as you see fit.
Perhaps there should be some kind of grace period, where anyone can download the contents of a "deleted" feed for *n* days before it gets removed entirely. That way, the user has the opportunity to download his feed and move it somewhere else and his followers have the opportunity to save an archive of the feed if they so choose.
> I honestly think the best way to handle this as we grow/scale with more pods in the Yarn.social network is to just build up a strong positive community and just have a “zero tolerance” attitude towards abuse and just nuke offending feeds/accounts without question.
I personally disagree with this moderation policy, but it's your right to enforce your rules as you see fit.
Perhaps there should be some kind of grace period, where anyone can download the contents of a "deleted" feed for *n* days before it gets removed entirely. That way, the user has the opportunity to download his feed and move it somewhere else.
We agree that the abuse of admin powers on his own pod is not a big concern because the software should protect the right of the users to migrate to a different pod.
A user of a pod certainly needs to trust the operator to some extent. Abuse of admin powers by the operator of your own pod isn't a big concern in theory because it can be countered by moving to a different pod or self-hosting your feed.
However, admin abuse is a real concern when the admin of a pod you're not using gets to police the content of your posts.
> Imagine if a pod operator decides a twt should be deleted, then this set off delete calls for that twt to all peered pods, which in turn propagate delete calls.
Fine, as long as the post is on *his own pod*. I don't think we need any kind of moderation on Pod A by the admin of Pod B. If a function like that is going to exist, it should at least be opt-in.
Users on any pod should be free to mute any feed or conversation they dislike, and pod admins should be free to "mute" entire pods if they so choose.
I may be misunderstanding you here, but the motive behind this delete API seems to be to police the activities of users on other pods.
If a pod admin decides to delete a post on his pod as you have, that deletion should eventually be propagated throughout the network. It's the same if a user chooses to delete his own post. However, you should not have any say over the deletion of a post on twt.nfld.uk. That's @jlj's decision to make.
I think @tkanos and I are in agreement here, but I don't want to speak for him.
https://web.archive.org/web/20110318135429/http://www.sandaleo.com:80/pantone.asp