Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)T

tinkralge

@ tinkralge @programming.dev

Posts
8
Comments
20
Joined
2 yr. ago

  • RFC: Suggestion to monetise without ads

    Jump

  • I look forward to the feedback :) Enjoy your vacation!

  • RFC: Suggestion to monetise without ads

    Jump

  • Why? If the tracking picks it up, then it'll be up to the user whether they want to transfer money via those methods. Someone did make me think that filtering donation methods would be useful. So if there are website that use a donation method you disapprove of or do not support, you don't have to transfer money to them.

  • RFC: Suggestion to monetise without ads

    Jump

  • I remember seeing this and losing track of it a year or more ago. But the ecosystem seems to have died about 2 years. Libraries are all 2+ years old. The downside I see with it is that it requires signing up to join the system, which is surely a blocker for many people. First you have to know about it, then you have to trust it, and then you have to find the people who use it.

    That said, I love the idea of being able to pay for anything with your web-browser. How far away we are from it though, I don't know. The name "interledger" is also unfortunate as it immediately makes you think "crypto", which will probably turn off a lot of people to the wallet.

    It isn't clear to me how the connection to the bank is actually made. Gatehub for example says SEPA and Wire transfers work, but so do XRP, and bitcoin. The wallet seems to be held by them, but does that make them a bank? Maybe I'm thinking to much about it...

    Maybe it warrants another look. But I do think that connecting the current world to easy donations is important. Web monetisation could be added later once it becomes a standard.

  • RFC: Suggestion to monetise without ads

    Jump

  • Is the main issue really tracking and consolidating microdonations, or is it transferring credit between these donation systems and traditional finance entities like banks and credit card networks?

    They are 2 main issues. As mentioned, you want to transfer the money to the right person, which means tracking (or collection, whatever term you want to assign to it). And you want to transfer in the first place. Since there are so many systems, and some that don't allow one-time donations, and people are all over the world, it definitely is a problem. That's why not doing it monthly but annually could help. But that does make me think that it should be possible for the user to filter donation methods. For example filtering out direct transfers to accounts outside of your region due to transfer costs. Thanks, I can add that.

    Which regulatory compliance things would apply to this in its current form? Or do you mean that connecting to a user's bank account would incur the wrath of the authorities?

  • Programming @programming.dev
    tinkralge @programming.dev

    RFC: Suggestion to monetise without ads

  • There seems to be a problem joining the matrix room

    Jump

  • Thanks for reporting. I hope it'll get resolved!

  • LibreWolf @lemmy.ml
    tinkralge @programming.dev

    There seems to be a problem joining the matrix room

    matrix.to
  • Deleted

    Permanently Deleted

    Jump

  • You typically want a slightly-more-elaborate approach than just handing the network a hash and then getting a file.

    [...]

    Blake 3 supports verified streaming as it is built upon merkle trees as you described. So is IPFS. As I mentioned, IPFS hashes are that of the tree, not the file contents themselves, but that doesn't help when you have a SHA256 sum of a file and want to download it. Maybe there are networks that map the SHA256 sum to a blake3 sum, an IPFS CID, or even an HTTP URI, but I don't know of one, hence the question here.

    BitTorrent and Hyphanet have mechanisms that do this.

    Do you know of a way to exploit that? A library maybe?

  • Deleted

    Permanently Deleted

    Jump

  • It's quite simple: I want to retrieveFile(fileHash) where fileHash is the output of md5sum $file or sha256sum $file, or whatever other hashing algorithm exists.

  • Deleted

    Permanently Deleted

    Jump

  • I'm not sure what your concern is. I'd basically like to call a function retrieveFile(fileHash) and get bytes back. Or call retrieveFileLocations(fileHash) and get URIs back to where the file can be downloaded. Also, it'll be opensource, so nothing to reverse engineer.

  • Deleted

    Permanently Deleted

    Jump

  • How do I retrieve a file from bittorrent with just its hash? Does WebMirror solve that? I'll have a look at it...

  • Deleted

    Permanently Deleted

    Jump

  • If you sha256sum $file and send that hash to somebody, they can't download the file from IPFS (unless it's <2MB IINM), that's the problem. And it can be any hashing algorithm md5, blake, whatever.

  • Are there ORMs for android that support many-to-many relationships?

    Jump

  • Thanks. It does look like the right library to use. A little surprising that it seems to be the only one that's up to date, but at least it exists!

  • Android Development @programming.dev
    tinkralge @programming.dev

    Are there ORMs for android that support many-to-many relationships?

  • PSA: /c/linux has a matrix chat!

    Jump

  • Sure, why not. I'm not the creator of the room 🙂

  • PSA: /c/linux has a matrix chat!

    Jump

  • I know that @Ategon@programming.dev is there. Maybe he can make you a mod there too? And the channel could be added to the sidebar of this community too.

  • Linux @programming.dev
    tinkralge @programming.dev

    PSA: /c/linux has a matrix chat!

    matrix.to

  • What are you working on this week? (Mar. 31, 2024)

    Jump

  • This week some more work was done on inheriteRS to support inheriting non-trait implementations of functions.

    Basically

     rust
        
use inheriters::specialisations;

specialisations!(
    struct Parent {
        attr1: u8,
    }
    impl Parent {
        fn from_parent(self) -> u8 { 8 }
        fn overridden(self) -> u8 { self.attr1 }
    }
    
    #[inherit(Child)]
    struct Child {
        attr2: u8,
    }
    impl Child {
        fn overridden(self) -> u8 { self.attr2 }
    }
);

    results in 

     rust
        
struct Parent {
    attr1: u8,
}
impl Parent {
    fn from_parent(self) -> u8 { 8 }
    fn overridden(self) -> u8 { self.attr1 }
}


struct Child {
    attr1: u8, // new
    attr2: u8,
}
impl Child {
    fn from_parent(self) -> u8 { 8 } // new
    fn overridden(self) -> u8 { self.attr2 }
}

    There might be some clean-up necessary code-wise and the README has to be expanded. But the project is well on its way to version 1! It's a pity codeberg doesn't have easy CI/CD yet nor domain hosting e.g inheriters.codeberg.io or something. So auto-formatting, testing, auto-tagging, etc. will have to come once I can convince myself to setup a VPS somewhere that hosts all that.

  • What are you working on this week? (Mar. 24, 2024)

    Jump

  • That sounds like fun! Wow. How stable is it at the moment?

  • What are you working on this week? (Mar. 24, 2024)

    Jump

  • Working on some form of inheritance in rust. It's my first foray into procedural macros and so far it's fun. The idea is quite simple: generate structs with common attributes (and eventually functions) instead writing them yourself.

     rs
        
use inheriters::specialisations;

specialisations!(
    struct Parent {
        attr1: u8,
    }
    #[inherit(Child)]
    struct Child {
        attr2: u8,
    }
);

    becomes

     rs
        
struct Parent {
    attr1: u8,
}
struct Child {
    attr1: u8,
    attr2: u8,
}

    not

     rs
        
struct Parent {
    attr1: u8,
}
struct Child {
    attr1: u8,
    parent: Parent,
}

    The latter leads to indirection which I'm not a fan of.

    Last week I squashed one bug on the order of attributes according to inheritance. In the example above attr2 was coming before attr1. A feature is nearly done to exclude the Parent from the output and only output the child. That's useful for parents that just serve as holders for shared attributes.

    The goal for v1 was to also support basic inheritance of implementations: Parent has an impl block, then that block is copied for the Child. Not sure yet if I'll implement overrides in v1 or v2. Overrides being if Parent implements do_something() and Child does too, then the implementation of Parent is not copied into the impl block.That's what I'll try to tackle in the coming weeks.

  • [Feedback request] Wiki page on packaging using builtins.derivation

    Jump

  • Great, thank you! I'll be moving on to mkDerivation soon. Hopefully budding packagers will be less intimidated than I was when I started.

  • Nix / NixOS @programming.dev
    tinkralge @programming.dev
    Feedback request

    Wiki page on packaging using builtins.derivation

    nixlang.wiki /en/nix/packaging/index
  • Nix / NixOS @programming.dev
    tinkralge @programming.dev

    Feedback for the nixlang wiki

    nixlang.wiki

  • [Rust] Simple predictive text review

    Jump

  • Thank you! I implemented some of the feedback (haven't pushed yet) and responded to the comments. Learned something 👍

  • How would you store symlinks on a cloud service?

    Jump
  • Programming @programming.dev
    tinkralge @programming.dev

    How would you store symlinks on a cloud service?

  • Code Review @programming.dev
    tinkralge @programming.dev
    Rust

    Simple predictive text review

    gitlab.com /NamingThingsIsHard/linux/chordnix/-/commit/3a1cf8ed40260b50c2704e340e04889092131f80