Skip to main content

Zoom Logo

Interledger Community Group Call - Shared screen with speaker view
Yuriy
08:31
Hi folks, Austin and Dino shared hackharvard.md (https://gist.github.com/austin-king/59bf8110ab81b657b262a4d3cabe721b) guide which is awesome way to play with ILP. I wonder if folks in the community have their favourite sites, apps or flows to play with ILP.I've started building out the prototype of the ILP browser, it's still ways to go but would be nice to start creating a list of apps/sites to test on.Thank you!
Yuriy Dybskiy
11:34
That would be awesome!
Solstice - Jonathan Fulton
11:37
With the new design, it sounds like you are putting the plugins in a position ahead of the backend servers that are clustered, which seems to protect the backend ... what protections for say DDoS ... are being built in for the plugins that sit on the edge/in front of the backend cluster?
Yuriy Dybskiy
12:09
Happy to take a look at drafts or early version of new connector “getting started” guides if you plan to have that ^_^
Solstice - Jonathan Fulton
14:36
Sounds good ... can't join audio today! Thanks Adran. The new design modularity sounds like it will be perfect for our Docker designs at Solstice
emschwartz
20:47
I can also give a small update on some pull payments related ideas
David Fuelling
23:39
After Evan, I have a quick question on the Connector Architecture…
David Fuelling
26:34
@Evan do you think there’s room for 2 distinct protocols here, one for “pull” and one for “delegation”, or do you think it would be better to have a single unified protocol for this?
Matthew de Haast
26:35
Would the token be encoded with limits and etc, or would the ILP packets need to be routed through the token issuer?
Solstice - Jonathan Fulton
27:35
With the modular design, and separation of components/services ... is the code being written so that each of these components can truly be standalone - with environment variables stipulating ip addresses/sockets/URIs to contact for each? I'm looking at it from the perspective of Docker (of course) and wondering if I can run each component as a service with its own dedicated thread/resources - instead of the manner in which a connector is today where all items are packed into one npm process. Also, in terms of the clustering - will these components be written to accept multiple IPs/sockets/URIs in a "pool" so that true clustering is available across all components for scaling and maximum uptime ability? (Sorry for the run on sentences)
Matthew de Haast
29:53
Thanks Evan, that’s really cool! I could image you could build so much off having this functionality. You could essentially allow someone to have wallets service issuing token to allow you to pay but the wallet deals with the money part
Matthew de Haast
30:05
Not to dissimilar to coil
Matthew de Haast
32:20
@Jonathan, yes each component has its own config that is pulled either from env or passed in configs. It does make dockerizing the individual components much easier. Yes exactly that would be possible
emschwartz
32:25
https://github.com/interledger/rfcs/issues/499
Matthew de Haast
33:36
With clustering, not sure yet
Solstice - Jonathan Fulton
36:29
It's like a pre-paid or chargeable credit card ... the user has a fixed amount - and doesnt have to understand anything other than that
Matthew de Haast
40:12
@Evan when you say BTP and blocking. Do you mean WS or the BTP protocol?
Matthew de Haast
41:44
Thanks yeah understood. So that’s not an issue with BTP so much as the transport layer
emschwartz
42:41
Yup!
vpestritto
55:41
@Adrian I was already discussing making this a blog post
vpestritto
55:48
Will let you know
Solstice - Jonathan Fulton
56:06
Thanks everyone for your work~!