3 ms·

A lot of applications have that problem though. Take a text editor, it would be improved if edits or saves which are just transactions are stores on a blockcha

by _8j50 4y ago

A lot of applications have that problem though. Take a text editor, it would be improved if edits or saves which are just transactions are stores on a blockchain if the text is being stored and shared synchronously and live between devices. Basically, people have more devices, want to collaborate and add redundancies to important systems which means changes to data (transaction) where the historical sequence of changes is important to someone can use blockchain, but of course it isn't neccesarily the best solution, especially if there is trust between nodes or out of sync nodes causing a mess can be solves by simpler solutions.

smoldesu 4y ago
Blockchains wouldn't fix anything here, though. The last-connected device doesn't necessarily have the canonical file, and the blockchain doesn't have any way to resolve syncing conflicts. Git is a much better choice for transactional history, and it didn't need a blockchain to implement this concept.
- _8j50 4y ago
  Git requires a human to resolve conflicts, a blockchain comes to a majority consensus. But yeah, I would use git and try to automate conflict resolution but it stands to reason blockchain can also solve the problem. If you have 10 people live-editing a text content git will be messy for example but you can come to a consensus on agreeing who made what changes and when between participants (assume p2p connection).
  - smoldesu 4y ago
    > but you can come to a consensus on agreeing who made what changes and when between participants How is this different from Git's model of development?
    - _8j50 4y ago
      Git is too slow for the use case I mentioned you resolve conflicts when you merge to your repo but you don't establish a consensus allowing everyone to accept your conflict resolution without centralizing.
      - smoldesu 4y ago
        Establishing consensus is more difficult than a single person deciding what to merge, if you need a trustless system then you can add consensus on top of Git.
        _8j50 4y ago
        Yeah and speed up git to commit/push/merge very fast. Or use a blockchain. I feel like there is stigma against the term, shall we call it distributed leger instead?
        smoldesu 4y ago
        You can call it a BitTorrent magnet for all I care, it doesn't change the fact that a distributed ledger only has so many uses. Git already has consensus mechanisms baked into it's architecture, and immutability is provided with GPG signing if you care enough about it. Both of those features have been available in Git since the 90s. You're not revolutionizing anything by proposing a migration to an even less ubiquitous protocol than HTTP or SSH.
        _8j50 4y ago
        > You're not revolutionizing anything by proposing a migration to an even less ubiquitous protocol than HTTP or SSH. I did not propose that. I didn't know git had a consensus mechanism built into it other than manual resolution of merge conflicts. A simple blockhain over https is easier for me than trying to get git to do something it wasn't designed to do (it works with files and repos, can you imagine having a commit+push+merge for every word edit in my example?) there are ready made libraries for this. The path of least resistance to acheive desires goals is what I would take. To each his own, blockhain can solve these problems outside of crypto. Another big problem area is PKI as well. I'm sure you've seen stories about suspicious CAs, a distributed ledger of CA issuance and in the wild certificate observations is one legitimate goal that can be solved by blockhain (better than centralized CT logs that don't take ITW observations).

by _8j50 4y ago

smoldesu 4y ago

Blockchains wouldn't fix anything here, though. The last-connected device doesn't necessarily have the canonical file, and the blockchain doesn't have any way to resolve syncing conflicts. Git is a much better choice for transactional history, and it didn't need a blockchain to implement this concept.

_8j50 4y ago
Git requires a human to resolve conflicts, a blockchain comes to a majority consensus. But yeah, I would use git and try to automate conflict resolution but it stands to reason blockchain can also solve the problem. If you have 10 people live-editing a text content git will be messy for example but you can come to a consensus on agreeing who made what changes and when between participants (assume p2p connection).
- smoldesu 4y ago
  > but you can come to a consensus on agreeing who made what changes and when between participants How is this different from Git's model of development?
  - _8j50 4y ago
    Git is too slow for the use case I mentioned you resolve conflicts when you merge to your repo but you don't establish a consensus allowing everyone to accept your conflict resolution without centralizing.
    - smoldesu 4y ago
      Establishing consensus is more difficult than a single person deciding what to merge, if you need a trustless system then you can add consensus on top of Git.
      - _8j50 4y ago
        Yeah and speed up git to commit/push/merge very fast. Or use a blockchain. I feel like there is stigma against the term, shall we call it distributed leger instead?
        smoldesu 4y ago
        You can call it a BitTorrent magnet for all I care, it doesn't change the fact that a distributed ledger only has so many uses. Git already has consensus mechanisms baked into it's architecture, and immutability is provided with GPG signing if you care enough about it. Both of those features have been available in Git since the 90s. You're not revolutionizing anything by proposing a migration to an even less ubiquitous protocol than HTTP or SSH.
        _8j50 4y ago
        > You're not revolutionizing anything by proposing a migration to an even less ubiquitous protocol than HTTP or SSH. I did not propose that. I didn't know git had a consensus mechanism built into it other than manual resolution of merge conflicts. A simple blockhain over https is easier for me than trying to get git to do something it wasn't designed to do (it works with files and repos, can you imagine having a commit+push+merge for every word edit in my example?) there are ready made libraries for this. The path of least resistance to acheive desires goals is what I would take. To each his own, blockhain can solve these problems outside of crypto. Another big problem area is PKI as well. I'm sure you've seen stories about suspicious CAs, a distributed ledger of CA issuance and in the wild certificate observations is one legitimate goal that can be solved by blockhain (better than centralized CT logs that don't take ITW observations).