Scenario: you're using opensource software and you aren't donating yet, however you have enough money left over every month to do so. Something(s) is holding you back from donating. Think about what that is and what would have to change for you to change that.
TL;DR detect donation options on a website, track website visits locally, show a monthly view of websites visited monthly with donation options, donate to your favorites (manually at first, automatically later - never worked in banking)
I'm sure a fair number read "monetisation" and though "that's ads". No. You've been conditioned to think that ads are the only way. They aren't. They are one of the worst.
Unfortunately, that's what many media creators, artists, writers, software developers, etc. assume. Peertube isn't a viable platform for creators because viewers have a lot of friction to give the creator money. Meanwhile, on platforms like youtube, all they have to do is view the video and everything else happens in the background.
What if we, the viewers, had an easier way to donate.
%money to my sub account (automatic transfer)%money is distributed, with an algorithm of my choosing, using the donation gateways of the stuff I consumedThis can all be done locally, without a server, and if need be stored per device, then aggregated via a local sync (WiFi, bluetooth, VPN, ...). Everything stays local, the bank just sees your outgoing transactions. Optimally, it would be with a private method of transferring money e.g Monero or GNU Taler.
These have their advantages and disadvantages, but together, they could cover most scenarios.
<head> for people who have created the thread.<meta property="og:donation" content="https://wero.eu/example" />document.querySelector("a").filter(isPaymentProvider).well-known/donation servers should put that file there with a documented JSON format
Look for custom headers e.g X-Donation: https://wero.eu/example
If I'm not mistaken, GNU Taler should have an API that allows connecting to an account, but it only has a testnet. Paying with crypto probably needs a server or something where you host your wallet, but it should be possible. Open Banking, after having a quick look requires some kind of registration to be able to access the API. IMO, nobody's going to hand over details like that unless it's considered normal and we're far away from that.
Therefore, the most likely is that the user will simply be presented with the algorithms to distribute money, the amounts to distribute, and the distribution methods. My best guess is that people get a quarterly, semesterly, or annual notification with the "It's time to donate!" window and they figure it out.
Advantages
<meta> tag which gives power to the operator to dynamically generate it (as described before).well-known/donationsDisadvantages
<meta> tags.well-known/donationsI'm curious about constructive criticism, improvement suggestions, or maybe even links to dispell some of my beliefs about Open Banking.
::: spoiler Previous inspiration
flattr was a micro transaction platform that supposedly did something like this, but it never gained steam. They acted as the tracker and distributor, but it required that server operators also register with flattr.
:::
I keep getting this error in element
MatrixError: [403] You do not belong to any of the required rooms/spaces to join this room. (https://matrix.org/_matrix/client/v3/join/%23librewolf%3Amatrix.org?server_name=matrix.org&via=matrix.org)
Anybody else?
I have no experience with android apps and just started working on one that needs to work with relational data. The relational data has multiple many-to-many relationships and the inbuilt ORM (Room) is leads to class explosion.
While looking at ORM libraries for android, there seem to be many that are out of date:
From 5 of the Best Android ORMs (2014) and AlexeyZatsepin/Android-ORM-benchmark (2017)
I'm leaning towards Requery because I like its API the most (hides SQL the most), but haven't looked at ObjectBox yet.
It's a WIP, but I hope it's understandable and contains the necessary information to start packaging something using the builtin derivation function.
Despite the name, the nixlang wiki is a community contributor wiki to document things around nix that the maintainers haven't gotten around to, to short-circuit the lengthy review process for the official documentation, and an attempt to make an entry into the nix ecosystem easier.
It's difficult to write things from a perspective of somebody who doesn't know, despite once being that person!
It would be great to have some feedback on the wiki.
P.S I'm not the maintainer, just a contributor.
TL;DR No archive format like tar, zip, ... but how would you theoretically represent a symlink in a manner that can be stored on the cloud and retrieved back to the system as a symlink?
Backstory
I heavily use symlinks to organise my media and even wrote an application that helps me do so (it's in Python and being rewritten in Rust). But I also use stuff like home-manager and nix which makes heavy use of symlinks.
My goal is to back up my media and /home to the cloud at regular intervals. There are services that cost just about 60-100€ yearly for limitless storage in the cloud. So having part of my library purely in the cloud and using terrabytes of space would cost less than a single 15TB HDD (500+€). To have a local backup, I'd even need a least a second one, which would put me at >1000€ - the equivalent of at least 10 years of cloud storage.
Options explored
It is pretty sweet as it supports mounting a cloud drive as a folder and has transparent encryption! However there are multiple open issues on uploading symlinks and I don't know Go. I wouldn't mind trying to learn it if I had an idea how to upload a symlink without following it (following symlinks breaks them).
git-annex etc.
git-annex and using a bare git repo with a remote worktree is great, but I don't need to make diffs of stuff and follow how things moved around, etc. I just need to replace backups with a view of what's there. Plus, storing all that history will probably take enormous amounts of space which is wasteful.
Ideas
store a blob of stat() call for every file
I'm not sure about this. The stat struct does contain information about the filetype (directory, hard link, symlink, ...), but my knowledge of linux internals is limited and maybe that's too complicated for this usecase.
a db of links
Instead of storing the links themselves, I store a DB (sqlite? CSV?) of links, upload that DB and use the DB to restore links after pull it back down. 🤔 Actually this might be the simplest thing to do, but maybe y'all have better ideas.
I wrote a simple algorithm for predictive text that uses preceding words as context. Without looking at prior, it was an attempt as seeing what I could come up with.
The goal is for it to be incorporated in chorded input and pick the best candidate for the entered chord with the given context. Chorded input is the method of hitting all keys for a word simultaneously instead of hitting each key individually in expected order.
E.g you've typed "this is the worst" and hit the chord "aet", which word should be chosen? ate? tea? eta? This algorithm is there to answer that.
What I'm looking for in the code review in order of importance:
The code is linted and automatically formatted.
![[Rust] Simple predictive text review](https://gitlab.com/uploads/-/system/project/avatar/52465100/chordnix-logo-hard-light-512x512.png){kind=logo}
https://gitlab.com/NamingThingsIsHard/linux/chordnix/-/commit/3a1cf8ed40260b50c2704e340e04889092131f80Open linkView original on programming.dev