realcr

I stumbled upon this article today. My first thought was that this is an interesting question, then I continued reading and thought that the solution ideas are kind of crude. Then I noticed it was written at 2018, so I realized we should give the author a break. Finally I realized that it was me who wrote this, 6 years ago!

So much has changed, but I believe the easy solution already existed back then. As people wrote in the comments here, one can iterate over an Option and then use flatten.

Strange experience indeed.

Thanks for making this! It looks super useful.

Will I be able to use console or part of it with the rest of the rust async ecosystem? (for example, async-std or futures-rs), Or is is Tokio specific?

My intention in dealing with planar networks is mostly the case of deploying a local mesh network. Most mesh networks behave like planar graphs. Not sure if this is an actual use case for matrix though.

Hey, I worked in a related research field a few years ago and published some of the results. Here are some ideas I find important:

- Generally I found that overlay DHT based routing is not very scalable for large graphs. It performs well for random looking graphs, but becomes very inefficient for large planar-like graphs. If pinecone is designed for small local networks, it might work well, but it will probably not scale well to large networks with the current design.

- With a small local hack to the Chord network, it is possible to achieve eventual connectivity, see here: https://www.freedomlayer.org/articles/chord_connected_routin...

Other pieces can be found here: https://www.freedomlayer.org/research/ Of special importance are the experiments performed to large networks, which can be found on this page: https://www.freedomlayer.org/research/landmarks-lookahead/

If anyone from the matrix team is reading this, I will be happy to help if any help if needed.

It's true. In addition, spolu gave some very useful pieces of advice during the design of Offset. Too bad settle.network is not live anymore.

I am not sure whether https://settlenetwork.com is actually affiliated with the original settle.network written by spolu.

This comment contains some really useful feedback. Highly appreciated. Not sure what would be a good branding instead of using the term "credit card". What do you think?

About the default servers, I always have the fear the system will become too centralized, so I tried to force the user to understand he can pick any server he wants. Maybe I am wrong here, this needs some extra consideration.

About the other defaults that seem convoluted: I picked those due to security considerations, but maybe you are correct, and it is better to leave things open by default there.

If you are interested in reviewing the next versions before they are published, please stay in touch. You can send me an email directly or join the mailing list if you like.

> Flow is limited by the narrowest pipe along the path

Ah, this was a concern I had too. To mitigate it, Offset allows paying using a multi-path: a few paths together. It happens atomically, and doesn't require intervention from the user.

I really enjoyed reading this.

Thanks for that! I am realcr on twitter, though not very active there. Best way to contact me is probably through email, see "contact" on the Offset website.

Thanks for the kind words! I am a great fan of the classic ripple myself.

This is intentional. I really know nothing about this space, but I hope to get help about from some friends in the future.

Yes, some friends offered a rename. I noticed that every time I wanted to tell someone about the project, I had to explain that it is written as Offset, but without the "e". It was always awkward, so offsetcredit.org it is.

Sorry, there is nothing you can buy with Offset right now! Maybe I should set up some kind of a demo website so that people can try it out.

One thing you can do is open two Offset cards on your own mobile phone, and try to pay with one card to the other (:

Hey osrec, I wish I was an ex-banker. This kind of experience would have really helped me when working on this.

For your questions:

> What if a bunch of people are offline and no path can be found?

If no path can be found, the transaction will fail. This is truly a weak point of Offset. I have been thinking about this for a while myself, here are the possible solutions:

1. Currently Offset takes a lot of battery to use (because of communication). Maybe in the future battery won't be a problem for mobile phones. In that case people will stay online and connected most of the time. The incentive might be to make money through fees.

2. Maybe some people will decide to be "hubs", and always be online. Offset has a desktop application too (though a CLI based at this time). You can run it as a server, so that it always online.

> Do you imagine certain nodes trying to become "hyperconnected" so that they may connect as many people as possible, and earn fees from providing this service?

Maybe. But I hope that there will always be enough competition, so that people will be able to find cheap enough routes.

> What algorithm do you use to compute the shortest/cheapest be path between two counterparties?

Currently, a very lousy algorithm, the most basic thing that works. This part really needs some work. My idea is that every index server could implement his own magic thing, and you could pick whatever index server you like.

> Does this scale well in a distributed, self-hosted system?

I think it does. Not sure that with the current implementation, but it might with some improvements.

> How does one establish a friendship/trust with another party,

Check the video, I show this one!

> and who sets the credit limits for the relationship?

Each party gets to pick one credit limit. If A and B have a relationship, A gets to choose how much B can ever owe A, and B can choose how much A can ever owe B. To summarize: You get the choose how a maximum cap for your fortune.

Hi. You are correct, you need to have some credit line, possibly indirect, between you and the other party, if you want to send money or receive money with Offset. This is the core of how Offset works.

> why wouldn't this model eventually end up with banker-type people managing the credit for everyone?

I thought about this question for a long time myself. As a first note, I don't think Offset should completely replace the traditional banking system. Everything has its place in the world. I admit that I still use my bank account daily.

If I understand correctly, your concern is that Offset might eventually become centralized, and therefore will return to the starting point: the banking system that we have today. I have some thoughts about this:

1. I believe that technology like Offset gives very convenient tools to make payments work in a decentralized way. It takes about three "bash" lines to set up an Offset node in the cloud, and you have your own credit hub. I agree that it takes a certain amount of credibility to open a credit hub, but I still believe it makes things much easier than opening your own bank nowdays.

2. There is this idea of 6 degrees of separation, where every two people in the world probably have a chain of friends between them that is of length no more than 6. If things actually work this may, it might be possible to pay using Offset without relying on central hubs.

There are two caveats to this idea though: (a) Currently Offset clients on mobile phones will eat your battery if you keep them open for too long. (b) You might not be able to make very large payments through the credit limits you set with your friends. Most people will trust their bank with $50000, but most people will not trust their friends with this amount of money.

About issue (a): Maybe it is temporary, and in 5 years we won't have these kind of battery limitations. For (b), I'm not sure yet myself. Maybe you will always need credible credit hubs to be able to make large payments.

3. Even if Offset becomes more centralized, based on a few credit hubs, I think that it is still better in some ways than the current ways banks work. (though note that I might be biased here).

a. Your money will be protected from inflation caused by state money printing.

b. Not much regulation is required, because the nature of Offset doesn't allow the "credit hubs" to do things like play with your money, generate new money through loans and more. More than that: Offset always provides the end user with a cryptographic proof about the amount of money in his account.

c. I expect that fees with Offset will be much lower than what you get with your banks.

d. It is easy to create Offset hubs, so there will always be competition.

e. Money will move through an auditable open protocol.

Offset is still pretty young and I am very far from having answers to everything. If you think something is still missing, please send a message.

Hey, interesting questions. Let me try and answer.

> I’d really kind to see a much more concrete specification

The best I can show you at this point is here: https://docs.offsetcredit.org/en/latest/theory/mutual_credit... This document is far from a full mathematical proof of safety, but it shows how things work. I expect the protocol to change in the next months, so I didn't want to be too detailed about the current protocol. Just to be sure it is known, Offset is open source, and you can find the full schema of communication here: https://github.com/freedomlayer/offset/tree/master/component...

> It feels like it’s easy to create identities, establish credit lines with no intent to repay

You can in fact create as many new identities as you wish with Offset, however, an identity doesn't worth much without established credit lines. Establishing a credit line requires human intervention. You will not be able to trick your human friend into adding your multiple identities of yourself as new credit lines to his Offset client. In other words, what protects you from Sybil attacks here is real world relationships with people.

If you ever decide to open your own "hub" or "bank" with Offset, giving credit lines to many strangers, you might want to have extra security, like maybe asking for their id card, or asking for some kind of collateral. But if the people you arrange credit line with aren't strangers, I don't think you have a real issue here.

> It only takes one bad actor to corrupt the chain of mutual credit

A bad actor can only compromise his direct "Offset friends", not a whole chain. When you set up your Offset node and add credit lines to your direct "Offset friends", you have to set up credit limits. Those credit limits limit how much money you can lose if any of your friends defaults. You can never lose more money than what you set up as your credit limits. If a friend of your friend defaults, your friend loses the money, not you.

> If a store doesn’t have a direct relationship with me it has to initiate a payment between an arbitrary number of intermediaries in order to fulfill the credit

Offset does this automatically for you. You don't really need to worry about this during the payment.

I might have missed something with my answers. Please tell me if you think something is missing!

Isn't square space a paid solution? https://www.squarespace.com/pricing

A decent wysiwyg website builder.

Hi, thanks for the interest! Actually, there is no ledger (:

Every two nodes that setup mutual credit maintain the balance between them. This turns out to be enough to be able to send funds across a chain of nodes in a secure manner.

Some of the general idea can be found here: https://offst.readthedocs.io/en/latest/theory/ It is a bit outdated given the modifications of the last few months, but I think it is still relevant enough to give you a better view of how things work.

https://www.offst.org : A decentralized credit card.

Still missing a reasonable GUI though. What I really liked about Rust in this project is the peace of mind it gives about safety, the performance, async features and the powerful procedural macros.

I experienced a similar problem. I'm using Firefox. Two websites I have great difficulties logging into are twitch.tv and italki.com, both require solving a google captcha that can sometimes take more than a minute to solve.

I am working on a micro-payments system (based on mutual credit) that should allow to pay something like $0.001 instead of solving a captcha. If this would introduce zero extra friction, would you consider using this kind of solution over the traditional captcha?

I think that there is a real opportunity here. I just went over all the comments about this idea. It seems like most of the objections relate to issues with the payment medium itself, and not with the actual idea of paying instead of solving a puzzle.

Some examples:

> It seems more likely they are trying to steal cc details by asking for such a small payment.

This relates to being afraid using a credit card online against a non credible seller.

> Payment processing is nontrivial to set up

This one is about the technical difficulty (And possibly also regulation) for setting up payment processing

> regions where it is uncommon to have means to interface with payment processors.

This one is about inaccessibility to payment means, which also relates to a problem with the payment medium.

> You could use JavaScript cryptocurrency mining instead

I assume that bo1024 suggested this because he implicitly believes that setting up a payment processor will be more difficult, and give bad experience to the user.

The only objection I have seen which is more specific to actually recognizing humans is this one (by Freak_NL)

> What would prevent the bots from using the same system?

First, I think that it should make operating bots on a wide scale much more expensive. Second, if you make money out of bots coming into your website, would you really care that they are bots? I assume that the reason someone would block bots from the first place is that bots harm their money making business. If you had a system to collect this money back, shouldn't this considered as a problem solved?

I am working these days on a decentralized payment system that supports micro-payments. (I promise there are no blockchains inside). Solving the captcha thing can be a very useful use case. I will be happy if anyone wants to join forces on this one (My email is real (at) freedomlayer (dot) org).

What if we had a mechanism that makes this kind of setup very trivial, and also risk free for the visitor? Then would you consider this kind of solution? EDIT: Same question for tty2300 (:

I had a strange idea about solving this problem: How about a micro-payment, something like $0.01, instead of solving a puzzle? In that case maybe you won't care if many bots login to your website.

I think that I by this time I have the technology to make something like this work, I was wondering if this is a good solution though. What do you think?

Hi, I am sorry if I misinterpreted what you have said earlier. let me try again. If I missed it this time too please send it again.

> A's promise. That's all great, however, if in the backwards path if A is offline or unresposive the transaction is left in a partially-committed state that hurts B, for example.

The core issue here the way I see it is that in the current design payments might take indefinite time. This is an issue I'm aware of, and I'm working these days on an atomic design for the transactions.

If you are interested, I can really use your help to review the proposal for the new design. I hope to have it done in the following week or two. My email can be found on freedomlayer's website on the about page. Please send me an email and I will inform you when the proposal is done.

> or since Offst is relying on indexes, relays and other server infrastructure it could as well rely on third-party commit registries.

I think that there are advantages to not relying on registries, and instead having every user run a node:

1. The way I see it, having only nodes is a general case of having both nodes and registries, because a registry is just a node that happens to be online most of the time and other people trust. This also means less code, less interfaces and less places to make mistakes.

2. The Offst protocol between two nodes gives cryptographic accountability between nodes. For example, if a node you are in contact with suddenly disappears, you can produce a cryptographic artifact that shows your last balance with that node.

A few people pointed out to me by that a transaction cancellation feature is missing. (Without it, the sender of a transaction might have to wait indefinitely). This is the next thing I'll be working on. Also, I agree that documentation is somewhat sparse, but I felt like I have to release something, even not complete, just to get some feedback about things I might be missing. Messages like yours are very helpful.

The way I see it, relying on dumb servers that only relay communication is very different than trusting third party registries. The worst that could happen with a bad relay is some communication problem, but if you trust a bad registry with your credits, it's a whole different story.

I very much hope so. Hopefully in the future you will be able to use Offst to generally buy stuff online.