00:00 <stellar-slack> <cyberomin> @dzham: almost all the telcos run their BTS using generators

00:00 <stellar-slack> <cyberomin> That said, they are places with poor mobile network

00:00 <stellar-slack> <dzham> OK, then you should do all this over SMS

00:00 <stellar-slack> <cyberomin> Connectivity becomes an issue

00:00 <stellar-slack> <cyberomin> @dzham: SMS is an option..

00:01 <stellar-slack> <dzham> SMS is definitely an option. I was talking with an organization in Senegal about a year ago when I realized SMS would work for "last mile"

00:01 <stellar-slack> <dzham> Don’t know how to get funding though, so haven’t done anything with it

00:01 <stellar-slack> <cyberomin> Oh ok

00:02 <stellar-slack> <cyberomin> Yes, SMS is one feature/aspect that should be explored.

01:17 <stellar-slack> <sacarlson> @scott I read your link about your ideas on offline payments. I like your term anchor that I to think is needed. I also have had interest in offline payment methods and we have spoke of it here before with dzham and I found that the payment channel sounded like a good method. I wrote a paper on it about 4 months ago that I don't think is updated with the payment channel part

01:18 <stellar-slack> https://github.com/sacarlson/stellar_utility/blob/master/docs/offline_transaction_algorithum.pdf

02:51 <stellar-slack> <brian.ebert> I got a deprecation warning from npm that URIjs is being replaced with urijs, so, trying to be helpful, I forked the sdk, made the changes and submitted a pr. The submission is failing a test. Can someone let me know how I should respond? This is the first pr I've submitted and I might need to be walked through the procedure. Thanks.

07:47 <stellar-slack> <scott> @dzham: If you are referring to the payment channel as described in sacarlson’s pdf, I don’t think it is quite the same. As I understand it, your system requires a pre-established (i.e. online) relationship between a merchant and customer, which IMO doesn’t really work with this use case. this protocol is specifically for things like the bus system here in lagos or small shops… the customer likely

07:47 <stellar-slack> the merchant prior to the moment of purchase.

07:48 <stellar-slack> <scott> Instead, we use the anchor (i.e. the gateway) as a shared trust and guarantor in the transaction

07:49 <stellar-slack> <sacarlson> yes that's the weakness in my posted idea, there needs to be some added trust or something more to fully work. I don't know how you can prevent double spending otherwise

07:49 <stellar-slack> <dzham> right, so the payment channel is between the customer/anchor, and anchor/merchant, respectively

07:50 <stellar-slack> <dzham> with sms you would just have a gateway that transcodes messages and submits them to the Stellar network

07:51 <stellar-slack> <sacarlson> oh with sms that's not really offline then

07:52 <stellar-slack> <dzham> well, no.. it’s offline as far as you don’t need to have an internet connection

07:52 <stellar-slack> <scott> I’m not convinced about SMS fully though, we’ve had severally people balk at it when we I mention it to them… the connectivity can be spotty and I specifically am trying to avoid intermittent connectivity issues that kill the transaction in this protocol

07:52 <stellar-slack> <dzham> and using the fact that regular mobile penetration is usually a lot higher than mobile internet

07:53 <stellar-slack> <dzham> @scott: gotcha

07:53 <stellar-slack> <scott> no reason we can’t have both thought! :)

07:54 <stellar-slack> <scott> sms will be great for environments where smartphone penetration is low but the infrastructure is more reliable

07:54 <stellar-slack> <dzham> I had some ideas about proper smart contracts a while back when we we’re thinking about offline tx’s, but that’s a whole layer on top of things

07:54 <stellar-slack> <dzham> But that would’ve solved offline

07:55 <stellar-slack> <scott> have you published any of you’re thoughts regarding your payment channel setup? or does that pdf reflect your work? I’d love to read about it if there is more

07:56 <stellar-slack> <sacarlson> yes but a full offline method should also be doable but I just don't see a perfect picture with no double spending. I think in scott's method he's going on the credit anchor gives the buyer in hopes he won't double spend and just drop the buyer if he does so. were the vendor is still garanteed there funds

07:57 <stellar-slack> <scott> @brian.ebert: I think @bartek is the appriopriate person to look into that test failure… he setup our sauce labs account (which seems to be why the suite is failing). I would ping him when he comes online

08:01 <stellar-slack> <sacarlson> there is more details on that payment channel method write by others but forgot the sources

08:01 <stellar-slack> <scott> @sacarlson: yeah, correct. Just like a bank will guarantee merchant funds in the case of stolen cards, the anchor could do the same. In this case, I think an anchor can handle it exactly as how personal checks are handled in america; You can overdraft your account by making too many payments (i.e. double spend) and you pay penalties to your bank (i.e. anchor) in the instances that you do.

08:02 <stellar-slack> <sacarlson> well I'm hoping to find a solution without that risk that the anchor has to take in this case, but so far this is about all we have

08:02 <stellar-slack> <scott> yeah, if you do, that would be even better! :)

08:03 <stellar-slack> <scott> well, I need to get out of bed and get cleaned up… cheers!

08:06 <stellar-slack> <sacarlson> at least with your basic method with intermitent internet we would just add blacklisted customer accounts same as stolen credit cards that might help your basic system

13:06 <stellar-slack> <bartek> https://stellar-public.slack.com/archives/dev/p1454208666000425 @brian.ebert: I've just merged your PR, thanks! the problem is connected with this: https://docs.travis-ci.com/user/pull-requests#Security-Restrictions-when-testing-Pull-Requests I will fix this tomorrow