Show HN: Offst – A decentralized payment system(freedomlayer.org)
freedomlayer.org
Show HN: Offst – A decentralized payment system
https://www.freedomlayer.org/offst/offst-release/
44 comments
> Hey, cool! I worked on something similar a long time ago
Great honor to get this message from you, I'm a great fan!
> Have you looked into using the Interledger Protocol?
Yes. It contains some things that I don't agree with. For example, I believe that the timeouts they have on the transactions are not secure. I also don't like that it binds users to the domain system and the traditional certificate hierarchy.
> Also, how do you propose to grow this network? That always seemed like the hardest part to me.
I'm not sure yet. I agree that this is a very difficult question. I might need some help.
Great honor to get this message from you, I'm a great fan!
> Have you looked into using the Interledger Protocol?
Yes. It contains some things that I don't agree with. For example, I believe that the timeouts they have on the transactions are not secure. I also don't like that it binds users to the domain system and the traditional certificate hierarchy.
> Also, how do you propose to grow this network? That always seemed like the hardest part to me.
I'm not sure yet. I agree that this is a very difficult question. I might need some help.
My advice would be to come up with a plan to grow the system and design the implementation around that.
Is this related to the modern day Ripple?
Yeah, the modern day ripple was a money based on debts, but it got bought out and replaced with a blockchain around 2013 once bitcoin got super popular, and the whole debt idea was wiped clean from ripple. The new owners just wanted the ripple brand.
Meanwhile, the debt idea is resurfacing on top of blockchains in the form of lightning payments. You can transact quickly via debts amongst a network of peers that settle their debts back to the blockchain for backing.
Meanwhile, the debt idea is resurfacing on top of blockchains in the form of lightning payments. You can transact quickly via debts amongst a network of peers that settle their debts back to the blockchain for backing.
Mutual credit accounts have been present at every stage. They became less popular than the cryptocurrency aspect for awhile, but Interledger renews the focus on credit, while allowing for cryptocurrency integration where it is effective.
Wrong. First there was Ryan Fugger's Ripple, then people bought the name from him to make an entirely different system (it had some resemblances in the beginning but they got smaller and smaller as the system was developed).
Um, that's exactly what I said. You didn't need to start your message with "wrong" when you agree with me.
I think this is a very interesting idea. A couple of questions:
1. Why is the mediation fee 1 credit? This appears to be an arbitrary choice with no rationale. Why not let the market decide?
2. What prevents me from setting up a fake node and just extending myself a bunch of credit? Is this where human judgement/trust comes in? I.e. my friends trusting me that I'm not engaged in this sort of manipulation? (I'm not saying this is inherently a flaw, just curious if you've considered it).
3. In the Alice, Bob, Charli example, why don't Bob and Charli just link up instead of more-expensively going through Alice?
I have my own answers to these questions, but I'm curious what your response is. I can see this project going in a slightly different direction from how you describe it in the initial release. Feel free to contact me at <my username> at gmail dot com if you're interested in discussing in more depth.
1. Why is the mediation fee 1 credit? This appears to be an arbitrary choice with no rationale. Why not let the market decide?
2. What prevents me from setting up a fake node and just extending myself a bunch of credit? Is this where human judgement/trust comes in? I.e. my friends trusting me that I'm not engaged in this sort of manipulation? (I'm not saying this is inherently a flaw, just curious if you've considered it).
3. In the Alice, Bob, Charli example, why don't Bob and Charli just link up instead of more-expensively going through Alice?
I have my own answers to these questions, but I'm curious what your response is. I can see this project going in a slightly different direction from how you describe it in the initial release. Feel free to contact me at <my username> at gmail dot com if you're interested in discussing in more depth.
Hi, let me try to answer:
1. Why is the mediation fee 1 credit?
In the beginning I had code that allowed any node to pick any fee he wants. This caused some problems. Because of the nature of this system, whenever you want to send funds along a route you have to know ahead of time all the fees along the route. If you got some route, and before you managed to send the funds one of the nodes decides to change his fees, your transaction will fail.
It's not a final decision though. I might add this feature again in the future. In the meantime if someone wants to collect 2 credits instead of 1, he can "simulate" another node. Then the route appears to be longer. Not optimal, but possible.
And why exactly 1 credit? This is the only arbitrary choice in the protocol, so it doesn't really limit anything, and it might actually give the credit its actual value in the protocol.
Another thing I was afraid of was some kind of credits inflation: All participants will start increasing their fees gradually. If we fix the fee to be exactly one credit, we can avoid this situation.
2. You can actually set as many fake nodes as you want, but it will not give you extra buying power on the outside world. For example: I can set up two nodes, each trusting the other one with 1 million credits. It will seem that I have lots of buying power (1 million credits!), but I will not be able to use this buying power outside of the clique of nodes I invented to myself.
Your buying power will always be limited by how other entities trust you, and this is something that might be hard to fake. You might be able to fake it once, but after the first time you default people will not be willing to trust you again (Hopefully).
One more thing: Offst has a way of producing a token that proves the last operation done in a mutual credit between two nodes. This token is signed, therefore we might be able to use it as a proof in a court. I haven't yet documented this feature, but it already exists in the first release of Offst.
3. They could, but maybe Bob and Charli don't really trust each other? Imagine that you are on a vacation, you go to some hotel in Shanghai and you want to pay for your stay. You could tell the hotel manager: Hey, why don't we open a mutual credit account and I could pay through that account. But it's not a good choice for the hotel manager, because most likely he will never see you again. It is better for him if you pay through a known route.
Thanks for the interesting questions, Prepare to get an email!
In the beginning I had code that allowed any node to pick any fee he wants. This caused some problems. Because of the nature of this system, whenever you want to send funds along a route you have to know ahead of time all the fees along the route. If you got some route, and before you managed to send the funds one of the nodes decides to change his fees, your transaction will fail.
It's not a final decision though. I might add this feature again in the future. In the meantime if someone wants to collect 2 credits instead of 1, he can "simulate" another node. Then the route appears to be longer. Not optimal, but possible.
And why exactly 1 credit? This is the only arbitrary choice in the protocol, so it doesn't really limit anything, and it might actually give the credit its actual value in the protocol.
Another thing I was afraid of was some kind of credits inflation: All participants will start increasing their fees gradually. If we fix the fee to be exactly one credit, we can avoid this situation.
2. You can actually set as many fake nodes as you want, but it will not give you extra buying power on the outside world. For example: I can set up two nodes, each trusting the other one with 1 million credits. It will seem that I have lots of buying power (1 million credits!), but I will not be able to use this buying power outside of the clique of nodes I invented to myself.
Your buying power will always be limited by how other entities trust you, and this is something that might be hard to fake. You might be able to fake it once, but after the first time you default people will not be willing to trust you again (Hopefully).
One more thing: Offst has a way of producing a token that proves the last operation done in a mutual credit between two nodes. This token is signed, therefore we might be able to use it as a proof in a court. I haven't yet documented this feature, but it already exists in the first release of Offst.
3. They could, but maybe Bob and Charli don't really trust each other? Imagine that you are on a vacation, you go to some hotel in Shanghai and you want to pay for your stay. You could tell the hotel manager: Hey, why don't we open a mutual credit account and I could pay through that account. But it's not a good choice for the hotel manager, because most likely he will never see you again. It is better for him if you pay through a known route.
Thanks for the interesting questions, Prepare to get an email!
Normally money is fungible and we trust the money, not the people. Pirates want gold because the gold will be accepted even if they won't be trusted.
This seems like an impossible obstacle -- every buyer and seller must have a connection (of trust), and the connection must have enough credit! Is the hotel manager in Shanghai going to have a connection to every customer? Is the local restaurant going to have thousand of trust connections so a relay can be found?
The other issue is the zero sum of credits and debits. How can money be added or removed from the system if "the total amount of credits in the system always remains 0"? How can you convert $100 USD to credits, spend the credits and someone else can get the $100? Does any money put into the system also need to removed at the same time? How would that work?
This seems like an impossible obstacle -- every buyer and seller must have a connection (of trust), and the connection must have enough credit! Is the hotel manager in Shanghai going to have a connection to every customer? Is the local restaurant going to have thousand of trust connections so a relay can be found?
The other issue is the zero sum of credits and debits. How can money be added or removed from the system if "the total amount of credits in the system always remains 0"? How can you convert $100 USD to credits, spend the credits and someone else can get the $100? Does any money put into the system also need to removed at the same time? How would that work?
> The other issue is the zero sum of credits and debits.
Let's say I've got 100USD. You've got a node and a pile of trusted friends. I spin up an account and pay you 100USD.
Initially it looks like this:
Me->Dollars: 100, Credits 0
You->Dollars: 0, Credits 0
What do I get in return? A line of credit that you extend to me. So now it looks something like this:
Me->Dollars: 0, Credits: 100
You->Dollars: 100, Credits: -100
It is up to you what you do with the cash, but there is now a debt on my account to you for what you provided to me. In this sense, a positive number of credits is "debt owed to another" and a negative number of credits is "debt that is owed to you".
Suppose I have a friend, CM, who I trust. If I want my 100USD, but you already spent your cash, I go to my friend and buy the cash with credits;
Before we trade
Me->Dollars:0, Credits: 100
CM->Dollars:???, Credits: 0
And after
Me->Dollars:100, Credits: 0
CM->Dollars:???-100, Credits: 100
Notice that you still have -100 credits. Essentially, I bought your trust. Because I gave you cash, you know that I'm good to pay you the money I've already given you. This debt owed to you will remain in the network until you are paid an equivalent amount in credit.
I can see now that lenders will be "debt sinks" that exchange cash for credit within the system. So, while the balance of the whole system is essentially 0, there will always be an imbalance because there will be those who take cash in exchange for "trust" and credit.
> Is the local restaurant going to have thousand of trust connections so a relay can be found?
No. The restaurant will trust a node that trusts many other people. I can see that as well as "debt sinks" on the network, there will also be nodes that specialize in taking on "trust" so that others don't have to. Like a bank. There will likely be a fee (in credits or cash, you choose) associated with assuming other's risks.
Let's say I've got 100USD. You've got a node and a pile of trusted friends. I spin up an account and pay you 100USD.
Initially it looks like this:
Me->Dollars: 100, Credits 0
You->Dollars: 0, Credits 0
What do I get in return? A line of credit that you extend to me. So now it looks something like this:
Me->Dollars: 0, Credits: 100
You->Dollars: 100, Credits: -100
It is up to you what you do with the cash, but there is now a debt on my account to you for what you provided to me. In this sense, a positive number of credits is "debt owed to another" and a negative number of credits is "debt that is owed to you".
Suppose I have a friend, CM, who I trust. If I want my 100USD, but you already spent your cash, I go to my friend and buy the cash with credits;
Before we trade
Me->Dollars:0, Credits: 100
CM->Dollars:???, Credits: 0
And after
Me->Dollars:100, Credits: 0
CM->Dollars:???-100, Credits: 100
Notice that you still have -100 credits. Essentially, I bought your trust. Because I gave you cash, you know that I'm good to pay you the money I've already given you. This debt owed to you will remain in the network until you are paid an equivalent amount in credit.
I can see now that lenders will be "debt sinks" that exchange cash for credit within the system. So, while the balance of the whole system is essentially 0, there will always be an imbalance because there will be those who take cash in exchange for "trust" and credit.
> Is the local restaurant going to have thousand of trust connections so a relay can be found?
No. The restaurant will trust a node that trusts many other people. I can see that as well as "debt sinks" on the network, there will also be nodes that specialize in taking on "trust" so that others don't have to. Like a bank. There will likely be a fee (in credits or cash, you choose) associated with assuming other's risks.
This is pretty cool. Obviously inspired by Ripple, but I like another implementation without cryptocurrecy or global consensus.
The key difference seems to be that there’s only one currency of account, credits. I find that interesting, not in a bad way.
Let’s say I started a trustworthy node. I offer to issue 1000 credits per bitcoin someone deposits. All publicly accountable and with some crypto black magic (for the sake of argument), trustless.
Would this create an off-chain payment solution?
The key difference seems to be that there’s only one currency of account, credits. I find that interesting, not in a bad way.
Let’s say I started a trustworthy node. I offer to issue 1000 credits per bitcoin someone deposits. All publicly accountable and with some crypto black magic (for the sake of argument), trustless.
Would this create an off-chain payment solution?
Yes, but you can't do it trustlessly not even with all the crypto black magic in the world. Otherwise it would be great.
People in Bitcoin space have been trying all possible off-chain payment solution they could think of. "Sidechains" are a concept similar to your thing where people deposit bitcoins, however they seem to be impossible to do on top of Bitcoin (and on top of Ethereum too, even though people there have all computation tricks in the world at their disposal).
In the Ethereum space people came up with something called "Plasma" that is supposed to solve this and allow a big number of off-chain system use-cases, but it has an insurmountable number of flaws when you look closer.
In the Bitcoin space, there's an idea for implementing sidechains in a trust-minimized way (not 100% secure, but relying on the same game-incentives the power Bitcoin itself) called "Drivechain". Most of the discussion you'll find about "sidechains" on the internet is either people pitching the drivechain solution or criticizing or ignoring it completely and talking about Liquid, an off-chain payment system managed by Blockstream that is not trustless nor has any game-incentives.
People in Bitcoin space have been trying all possible off-chain payment solution they could think of. "Sidechains" are a concept similar to your thing where people deposit bitcoins, however they seem to be impossible to do on top of Bitcoin (and on top of Ethereum too, even though people there have all computation tricks in the world at their disposal).
In the Ethereum space people came up with something called "Plasma" that is supposed to solve this and allow a big number of off-chain system use-cases, but it has an insurmountable number of flaws when you look closer.
In the Bitcoin space, there's an idea for implementing sidechains in a trust-minimized way (not 100% secure, but relying on the same game-incentives the power Bitcoin itself) called "Drivechain". Most of the discussion you'll find about "sidechains" on the internet is either people pitching the drivechain solution or criticizing or ignoring it completely and talking about Liquid, an off-chain payment system managed by Blockstream that is not trustless nor has any game-incentives.
> there’s only one currency of account, credits
This is spot on.
> Would this create an off-chain payment solution?
I think that the lightning network does this kind of thing.
This is spot on.
> Would this create an off-chain payment solution?
I think that the lightning network does this kind of thing.
I think this is the right direction as I think all money is a form of debt - usually coupled with some settlement mechanism. Once we get a good implementation of debt settlement then I think we might actually get a usable decentralised money.
As a few comments have pointed out this similar to the Lightening network and Ripple. One comment mentioned that Ripple never found a routing algorithm and that is also a major criticism of Lightening, see for example [1].
How are you planning to address these challenges?
[1] https://www.youtube.com/watch?v=Ug8NH67_EfE
P.S. I only came across Rick Falkvinge today so I don't know how controversial he is in the crypto space. Given that he backs BCH I guess he might be.
As a few comments have pointed out this similar to the Lightening network and Ripple. One comment mentioned that Ripple never found a routing algorithm and that is also a major criticism of Lightening, see for example [1].
How are you planning to address these challenges?
[1] https://www.youtube.com/watch?v=Ug8NH67_EfE
P.S. I only came across Rick Falkvinge today so I don't know how controversial he is in the crypto space. Given that he backs BCH I guess he might be.
All the ideas are simple and as old as Fugger's Ripple. The part that is missing to all "mutual credit" payment system is how to do atomic transactions.
The linked article doesn't explain that which should be the most important and non-trivial part of the entire thing, it only says:
> The core of Offst is the credit pushing mechanism. It allows to send credits along a route of mutual credit edges in a secure way. You can read more about it in the project documentation.
The project documentation doesn't have a section dedicated to explaining how they solve these problems. Or at least I couldn't find it.
EDIT:
I found it, it's called "Introduction to backwards credit payment". Basically A sends a promise to B and B a promise to C, then C signs some stuff that fulfills B's promise and B signs some stuff that fulfills 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.
See discussion of this and many many other ideas (all flawed in some way or another) at http://ripple.ryanfugger.com/Protocol/Index.html
The Lightning Network implements the same "backwards" stuff. However the transaction cannot be abandoned in the middle because the HTLCs can be enforced on the blockchain (of course this has problems because most of the times it's not economical to enforce these things on the blockchain, but anyway).
EDIT 2:
I'm not saying this to shit on the idea. I really think it could work if it's based on real-life relationships so A is not going to try to cheat on B during a transaction, but at the same time if that is true we probably don't need so much commit things and signatures.
Now back to trust-minimized schemes, perhaps Interledger's idea of streams of minimal payments could work better in this context, or since Offst is relying on indexes, relays and other server infrastructure it could as well rely on third-party commit registries.
The linked article doesn't explain that which should be the most important and non-trivial part of the entire thing, it only says:
> The core of Offst is the credit pushing mechanism. It allows to send credits along a route of mutual credit edges in a secure way. You can read more about it in the project documentation.
The project documentation doesn't have a section dedicated to explaining how they solve these problems. Or at least I couldn't find it.
EDIT:
I found it, it's called "Introduction to backwards credit payment". Basically A sends a promise to B and B a promise to C, then C signs some stuff that fulfills B's promise and B signs some stuff that fulfills 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.
See discussion of this and many many other ideas (all flawed in some way or another) at http://ripple.ryanfugger.com/Protocol/Index.html
The Lightning Network implements the same "backwards" stuff. However the transaction cannot be abandoned in the middle because the HTLCs can be enforced on the blockchain (of course this has problems because most of the times it's not economical to enforce these things on the blockchain, but anyway).
EDIT 2:
I'm not saying this to shit on the idea. I really think it could work if it's based on real-life relationships so A is not going to try to cheat on B during a transaction, but at the same time if that is true we probably don't need so much commit things and signatures.
Now back to trust-minimized schemes, perhaps Interledger's idea of streams of minimal payments could work better in this context, or since Offst is relying on indexes, relays and other server infrastructure it could as well rely on third-party commit registries.
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.
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.
That's not what I said.
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'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.
There's a very similar project called Interledger.
It uses the same mechanism of credit payments over multiple hops. But denominates each hop in a particular (possibly different) asset to help settling the credit between peers.
It uses the same mechanism of credit payments over multiple hops. But denominates each hop in a particular (possibly different) asset to help settling the credit between peers.
It's true. I think that the main difference between the two projects is that in Offst there is only one type of credit. Interledger attempts to bridge between various ledgers.
So this is like the lightning network, but channel balances are never closed out to any kind of global ledger? If this were to be put into use, you would run into the following problem very quickly:
Bob’s debt to Alice grows beyond the point where Alice is willing to trust him since Bob is mostly using the system to buy things.
Bob’s debt to Alice grows beyond the point where Alice is willing to trust him since Bob is mostly using the system to buy things.
Offst includes the ability for Alice to set limits on her credit to Bob which would prevent this.
Sure, Bob is still out of luck though. This only works if Bob also receives an equivalent amount of income through his channel with Alice which is extremely unlikely.
Edit: I speak from experience, working on althea.org which included a similar system (although ours is backed by a blockchain and doesn’t require nodes to trust each other). The reality is that most nodes are either mostly paying or mostly being paid. The channels must constantly be refilled anyway because of this. We found that the saved transaction fees were not worth the complexity, and now nodes just use on chain transactions with no transitive trust system after about 50 cents of debt has built up in either direction.
Edit: I speak from experience, working on althea.org which included a similar system (although ours is backed by a blockchain and doesn’t require nodes to trust each other). The reality is that most nodes are either mostly paying or mostly being paid. The channels must constantly be refilled anyway because of this. We found that the saved transaction fees were not worth the complexity, and now nodes just use on chain transactions with no transitive trust system after about 50 cents of debt has built up in either direction.
> I speak from experience, working on althea.org
I follow you people for a long time on /r/darknetplan! How are things going?
As tmacro noted, Offst friends put credit limits on each other. Therefore Bob will not be able to buy forever. This is not really a bug, Bob is out of credits and shouldn't be able to buy more things until he gets new ones.
How does Bob gets credits is another question. In a normal economy Bob would have to get to work or exchange something to get credits. I agree with you that initially in a small network this could be a problem, because maybe nobody in the network wants to exchange something with Bob for credits. But if this kind of credit system is widely use, I hope this won't be a problem.
I follow you people for a long time on /r/darknetplan! How are things going?
As tmacro noted, Offst friends put credit limits on each other. Therefore Bob will not be able to buy forever. This is not really a bug, Bob is out of credits and shouldn't be able to buy more things until he gets new ones.
How does Bob gets credits is another question. In a normal economy Bob would have to get to work or exchange something to get credits. I agree with you that initially in a small network this could be a problem, because maybe nobody in the network wants to exchange something with Bob for credits. But if this kind of credit system is widely use, I hope this won't be a problem.
Could this be integrated to ActivityPub-based services, like PeerTube, Mastodon, Friendica etc.? That was one of the missing pieces for independent infrastructure, e.g. for paying artists or developers for their work without getting frozen by PayPal & similar once money start flowing.
I very much hope so. Hopefully in the future you will be able to use Offst to generally buy stuff online.
Interesting! Do you plan a less nerdy user interface? I'm afraid to say so, but a mobile phone app could be a game changer. (Yes, it would drain the battery, and yes, it could run on an old phone because many people have them in their shelves)
> Do you plan a less nerdy user interface?
Yes! I agree with you, having Offst on a mobile phone is indeed a game changer. Offst was designed from the beginning to work in environments where sudden malfunctions and network problems can occur. Having it on a mobile phone is part of the plan.
I began with a command line interface (stctrl, the first Offst application) because I knew I could finish developing it very quickly.
I hope to take a period of time to stabilize the protocol and all the APIs, and then I will begin writing a GUI interface for Offst.
Offst is written in Rust, I have no idea yet how to get it inside a mobile phone. I don't have any mobile experience at all, it will take some research on my side.
> it would drain the battery
Maybe not so much? Offst doesn't do any kind of CPU intensive operation. Maybe the communication will drain some battery though.
Yes! I agree with you, having Offst on a mobile phone is indeed a game changer. Offst was designed from the beginning to work in environments where sudden malfunctions and network problems can occur. Having it on a mobile phone is part of the plan.
I began with a command line interface (stctrl, the first Offst application) because I knew I could finish developing it very quickly.
I hope to take a period of time to stabilize the protocol and all the APIs, and then I will begin writing a GUI interface for Offst.
Offst is written in Rust, I have no idea yet how to get it inside a mobile phone. I don't have any mobile experience at all, it will take some research on my side.
> it would drain the battery
Maybe not so much? Offst doesn't do any kind of CPU intensive operation. Maybe the communication will drain some battery though.
When I last did mobile stuff, waking the radio was more expensive than many CPU ops.
We just have to hope that I until I manage to set up a nice UI for mobile phones, we will already have very good batteries (;
What's the use case you had in mind? Running offst as a daemon on an average 8h-a-day workstation/PC/Laptop? Or on a server? In any case, a mobile phone is basically offline most time -- It seems to be online thanks to push-services like the Google or Apple cloud ones, but that API is hardly usable for offset without some kind of relay server (however, you do have relays already in the design, which is neat).
However, running a networking service (daemon, app, whatever you want to call it) 24h on a mobile phone will massively drain the battery, just because Wifi et al needs some power.
However, running a networking service (daemon, app, whatever you want to call it) 24h on a mobile phone will massively drain the battery, just because Wifi et al needs some power.
I owe two friends money right now, and I have two friends who owe me more than that.
In order for this to work I've got to get the one who owes me to agree to create these credits and give them to me. Then, when I pay the credits to my 2 friends I owe, who is going to buy those so they can get their money out? How do I get the rest of my money out?
How could these debts be traded? Why would anyone buy them when they have to trust specific people they don't even know, and who may not even exist, to honor them?
The original Ripple concept failed for very good reason. When there's enough trust/credit/goodwill systems such as this don't add any value, and when there isn't they are useless.
In order for this to work I've got to get the one who owes me to agree to create these credits and give them to me. Then, when I pay the credits to my 2 friends I owe, who is going to buy those so they can get their money out? How do I get the rest of my money out?
How could these debts be traded? Why would anyone buy them when they have to trust specific people they don't even know, and who may not even exist, to honor them?
The original Ripple concept failed for very good reason. When there's enough trust/credit/goodwill systems such as this don't add any value, and when there isn't they are useless.
The original Ripple concept failed for an entirely different reason: no one could come up with a good routing and atomic payments implementation. Then Bitcoin appeared.
I don't know why you're presenting such a wrong narrative as if it was the absolute truth everyone agrees.
I don't know why you're presenting such a wrong narrative as if it was the absolute truth everyone agrees.
What year did Ripple debut?
Ripple was never implemented.
They were certainly promoting that concept in 2012, and for years after that. Remember, everyone was going to be able to release their own promises on it... so you could have a Euro backed promise from X which you could swap on chain against some USD backed promise from Y? And XRP was supposed to be just the fee currency to pay for it?
Am I wrong here?
Did Ripple predate Bitcoin?
Am I wrong here?
Did Ripple predate Bitcoin?
I don't see an API or network protocol. Will this be provided at some point?
It was very important for me to have the protocol schema separated from all the code, you can find it here:
https://github.com/freedomlayer/offst/tree/master/components...
This contains a capnp definition of all the protocol.
I didn't write about it yet in the documentation because I'm pretty sure this protocol is going to break soon. This first version is only a demonstration, and there are some various small things I might decide to change there.
I also want to change all the interface related Rust crates to have an MIT license, so that you can just copy the interface and do what you want with it. This should allow anyone to write applications with any license they want.
I intend to have a very detailed explanation of the protocol on the first stable release.
EDIT: One more thing that should be fixed in this regard is the format of the Offst database. Currently it is a file, I intend to change it into an sqlite database.
https://github.com/freedomlayer/offst/tree/master/components...
This contains a capnp definition of all the protocol.
I didn't write about it yet in the documentation because I'm pretty sure this protocol is going to break soon. This first version is only a demonstration, and there are some various small things I might decide to change there.
I also want to change all the interface related Rust crates to have an MIT license, so that you can just copy the interface and do what you want with it. This should allow anyone to write applications with any license they want.
I intend to have a very detailed explanation of the protocol on the first stable release.
EDIT: One more thing that should be fixed in this regard is the format of the Offst database. Currently it is a file, I intend to change it into an sqlite database.
http://ripple.ryanfugger.com/
Have you looked into using the Interledger Protocol? It's the most advanced evolution of the concept I know:
https://interledger.org/
Also, how do you propose to grow this network? That always seemed like the hardest part to me.