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.
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.
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.
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.
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.
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.
> 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!
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.
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.
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.