Welcome to the Daily General Discussion on Ethfinance

https://i.imgur.com/pRnZJov.jpg

Be awesome to one another and be sure to contribute the most high quality posts over on our sister magazines. Or guide them here for help and community, too!

Daily Doots Rich List - https://dailydoots.com/

community calendar: via Ethstaker https://ethstaker.cc/event-calendar/

“Find and post crypto jobs.” https://cryptojobs.gg/

  • kbrot@kbin.socialOP
    0·
    1 year ago

    At this time, my understanding is that content is nominally mirrored – not “mirrored” in the sense of the word any IT pro would use. Should an instance go down…

    • First, the two would coincide. There’s nothing at this time “destructive” in starting up another m/ethfinance on any kbin instance, or lemmy instance, or anywhere in the fediverse. It would live there just like r/gaming and r/games and r/truegaming do, and users would gravitate toward the community best fitting them.
    • Threads/comments/external links/posts (in the microblog) are cataloged by any other instance that properly federated and subscribed to the magazine from the point at which a user subscribed.
    • So, let’s say I or someone else signed up over on new kbin server readit.buzz, we’d have to register on readit as a user there, then browse to and subscribe to ethfinance@kbin.social to start bringing over data. I’ve seen signs that the number of cross-subscribers (inventing this term) on a given instance helps prioritize the speed of syncing.
    • Caveats are as you’ve mentioned before: the data earlier than subscription is not brought over, original media is lost unless re-hosted elsewhere, and perhaps most importantly… the links are erased from time (eg. Google searches) so that archival threads, well, aren’t. It’s similar to the days of lost phpBB communities and forums in that regard.
    • Lastly, it is a very easy process to backup and transfer the database. However, because there is at least one step involved there with an admin, we cannot yet call it anywhere near “trustless”
    • I believe admin Sign-in With Ethereum (via Safe) partially solves this and a VPS company accepting Safe SiWE nearly entirely solves it. But that’s a wish and a dream at this point. (Sidenote: what’s the old dApp that used to parcel out CPU cycles for tokens, was it Gnosis? Or something else with a G?)
    • hanniabu@kbin.social
      1·
      1 year ago

      First, the two would coincide. There’s nothing at this time “destructive” in starting up another m/ethfinance on any kbin instance, or lemmy instance, or anywhere in the fediverse. It would live there just like r/gaming and r/games and r/truegaming do, and users would gravitate toward the community best fitting them.

      Okay on closer look I see that the subs are distinguished by being prefixed with the instance name

      Threads/comments/external links/posts (in the microblog) are cataloged by any other instance that properly federated and subscribed to the magazine from the point at which a user subscribed.

      This is a part I need to understand better. So let’s say we have your private instance, what causes it to get mirrored? From this comment it sounds like someone subscribing would cause it to get mirrored but that would be it already exists, otherwise how would they subscribe. Is there some prior action that’s needed for it to get picked up?

      So, let’s say I or someone else signed up over on new kbin server readit.buzz, we’d have to register on readit as a user there, then browse to and subscribe to ethfinance@kbin.social to start bringing over data. I’ve seen signs that the number of cross-subscribers (inventing this term) on a given instance helps prioritize the speed of syncing.

      Do you have time to check if you can impersonate yourself? Aka sign up on an instance where kbin is mirrored using “kbrot” as the username, and posting in the daily thread. If that’s possible I think that’s a big problem.

      Caveats are as you’ve mentioned before: the data earlier than subscription is not brought over, original media is lost unless re-hosted elsewhere, and perhaps most importantly… the links are erased from time (eg. Google searches) so that archival threads, well, aren’t. It’s similar to the days of lost phpBB communities and forums in that regard.

      Lastly, it is a very easy process to backup and transfer the database. However, because there is at least one step involved there with an admin, we cannot yet call it anywhere near “trustless”
      I believe admin Sign-in With Ethereum (via Safe) partially solves this and a VPS company accepting Safe SiWE nearly entirely solves it. But that’s a wish and a dream at this point.

      You’d still be trusting whoever is the person to actually export/upload. However, this could be solved via github. Create a PR to merge an back, let’s say monthly. PRs must be reviewed in order to merge. The reviewers are other mods that export and can confirm parity by confirming hashes before merging.

      (Sidenote: what’s the old dApp that used to parcel out CPU cycles for tokens, was it Gnosis? Or something else with a G?)

      Golem?

      So back to your instance, should we be using that instead of using this? Or is there no need since we can export the data and launch our own instance at a later time if needed?

      • kbrot@kbin.socialOP
        1·
        1 year ago

        From what I can tell, subscribing from another instance creates a new community/magazine there on that instance which is fed by the original. So upon a fedia.io user subscribing to us here, they’d general something like: fedia.io/m/ethfinance@kbin.social. And my understanding is it begins collecting data from kbin once that link is established. My understanding is prior content isn’t brought over.

        I’ll check on the username thing but I do believe it’s what you fear… a username on one server doesn’t preclude it from being registered letter for letter on another. Because with current tools, how could it? That’s definitely something to look into and goddamn would web3/ethereum-based authentication be amazing for that verification process!

        So back to your instance, should we be using that instead of using this?

        Certainly not at this time, if only because it doesn’t really work yet. I don’t know how the first migration would work since the database would be coming from kbin.social’s owner ernest himself. We can’t trust that this initial magazine will be preserved, only hope. After that once a person in our community controls the DB – or a committee or DAO – then yes, it’s an easy transfer via rsycn/rclone/pick your poison.

        • hanniabu@kbin.social
          1·
          1 year ago

          So upon a fedia.io user subscribing to us here, they’d general something like: fedia.io/m/ethfinance@kbin.social.

          But how does a user from another instance subscribe to this magazine here? If they’re from another instance and theu came here then their login would be unassociated and they’d need to make a new login

          I don’t know how the first migration would work since the database would be coming from kbin.social’s owner ernest himself.

          As a backup plan what if we used your insurance to mirror this one. Then if we can’t get a backup from him then we will at least have the backup of your instance.