stebalien changed the topic of #ipfs to: Heads Up: To talk, you need to register your nick! Announcements: go-ipfs 0.5.1 and js-ipfs 0.43.1 are out! Get them from dist.ipfs.io and npm respectively! | Also: #libp2p #ipfs-cluster #filecoin #ipfs-dev | IPFS: https://github.com/ipfs/ipfs | Logs: https://view.matrix.org/room/!yhqiEdqNjyPbxtUjzm:matrix.org/ | Forums: https://discuss.ipfs.io | Code of Conduct: https://git.io/vVBS0
xcm has joined #ipfs
LinusCDE has joined #ipfs
maggotbrain has joined #ipfs
kivutar has quit [Ping timeout: 265 seconds]
ipfs-stackbot2 has quit [Remote host closed the connection]
ipfs-stackbot1 has joined #ipfs
<stebalien>
mrus: china or Spain?
<JCaesar>
_dnslink.マリウス.com descriptive text "dnslink=/ipns/QmbN1HddmFCNZV7ZJkxKb5VtQWmwUBCoviDjX2ABZp7XuQ"
<JCaesar>
So it's dnslink+ipns, no?
cp- has joined #ipfs
<aschmahmann[m]>
ah, you're right that explains the resolution time. Things resolve fine for me, not sure if mrus has any trouble resolving anything else via the gateway, if they run into other problems might be an ISP block or something
<mrus[m]>
<stebalien "mrus: china or Spain?"> Spain
<mrus[m]>
<JCaesar "So it's dnslink+ipns, no?"> correct, that's how it's supposed to work, no?
<mrus[m]>
<aschmahmann[m] "ah, you're right that explains t"> Just connected via ProtonVPN and everything resolves within a couple of seconds and gateway works fine.. so yes, looks like some ISP blocking there.
<mrus[m]>
I've just created an issue on github
danilom has quit [Ping timeout: 260 seconds]
<JCaesar>
Not necessarily. You can also throw dnslink=/ipfs/QmFoo into there. Resolving IPNS names generally takes some time.
gavlee has joined #ipfs
<mrus[m]>
<JCaesar "Not necessarily. You can also th"> Hm, not sure if I'd want to update DNS myself every time the site changes though
kivutar has joined #ipfs
<aschmahmann[m]>
^^ yep, the tradeoff is that if you use an dnslink -> ipns -> ipfs then you only have to update your DNS record once
<mrus[m]>
yeah
<aschmahmann[m]>
as more people update to go-ipfs 0.5.0 IPNS resolution times should decrease though
<JCaesar>
I admit, setting up bind9 to do RFC2136 updates was... annoying.
<aschmahmann[m]>
enabling IPNS over PubSub should also decrease resolution times because then it's extremely likely that peers (including the gateway) won't need to do a DHT search for the IPFS data since they'll already be connected to a peer who has it.
p8m_ has joined #ipfs
p8m has quit [Ping timeout: 258 seconds]
<mrus[m]>
hah bind9, ouch. :-) For me it wouldn't be even *that* hard since it would basically only require a `terraform apply`. Nevertheless I do like the IPNS concept and would like to keep it in place. :) regarding PubSub, RubenKelevra told me how to do that before and I do have the necessary flags in place.
fabianhjr has quit [Quit: Leaving.]
danilom has joined #ipfs
g2anj has joined #ipfs
gimzmoe has quit [Ping timeout: 265 seconds]
gimzmoe has joined #ipfs
Ecran has quit [Quit: Going offline, see ya! (www.adiirc.com)]
kivutar has quit [Ping timeout: 265 seconds]
stripedpajamas has quit [Quit: sleeping...]
kivutar has joined #ipfs
Belkaar has quit [Ping timeout: 240 seconds]
Belkaar has joined #ipfs
Belkaar has quit [Changing host]
Belkaar has joined #ipfs
stripedpajamas has joined #ipfs
Acacia has quit [Ping timeout: 272 seconds]
p8m has joined #ipfs
Acacia has joined #ipfs
KindTwo has joined #ipfs
p8m_ has quit [Ping timeout: 264 seconds]
<JCaesar>
aschmahmann: I've heard that promise for more than a year now, I think...
KindOne has quit [Ping timeout: 272 seconds]
mowcat has quit [Remote host closed the connection]
KindTwo is now known as KindOne
<vdmokstati[m]>
<RubenKelevra[m] "This overview is pretty dope. Wo"> can we get a list for all of this with urls.. after can make clickable links somewhere...
<aschmahmann[m]>
ˈt͡sɛːzaɐ̯: which promise. IPNS performance improvements? I guess the skepticism is fair enough given how long its performance has been a problem. go-ipfs 0.5 was a huge release with a lot of improvements, however the DHT is a cooperative structure so older nodes that have worse characteristics to end up affecting the network. There's some work underway to try and make DHT updates easier and allow new nodes to bene
<aschmahmann[m]>
even while older nodes lag behind.
kivutar has quit [Ping timeout: 256 seconds]
lord| has quit [Ping timeout: 265 seconds]
lord| has joined #ipfs
AbramAdelmo has joined #ipfs
mauz555 has joined #ipfs
kivutar has joined #ipfs
<JCaesar>
The promise of IPNS performance improvements indeed. But you're right, 0.5 had quite some impact.
AbramAdelmo has quit [Ping timeout: 260 seconds]
mauz555 has quit [Ping timeout: 260 seconds]
p8m has quit [Ping timeout: 256 seconds]
user_51 has quit [Ping timeout: 260 seconds]
jrt is now known as Guest81916
jrt has joined #ipfs
user_51 has joined #ipfs
Guest81916 has quit [Ping timeout: 272 seconds]
Trieste has quit [Ping timeout: 265 seconds]
Trieste has joined #ipfs
andi- has joined #ipfs
aesthe has quit [Quit: Leaving]
jcea has quit [Quit: jcea]
KindOne has quit [Ping timeout: 260 seconds]
KindOne has joined #ipfs
KindTwo has joined #ipfs
_jrjsmrtn has joined #ipfs
KindOne has quit [Ping timeout: 272 seconds]
KindTwo is now known as KindOne
kivutar has quit [Ping timeout: 246 seconds]
kivutar has joined #ipfs
<JakeHemmerle[m]>
hsn: do you know the name of said program for managing git repos over IPFS that supports PRs?
treora has joined #ipfs
AbramAdelmo has joined #ipfs
AbramAdelmo has quit [Ping timeout: 260 seconds]
_whitelogger has joined #ipfs
kivutar has quit [Ping timeout: 265 seconds]
endvra has quit [Read error: Connection reset by peer]
<dadepo[m]>
I also find it strange that `stderr` is being used for something that is obviously not an error but log information :|
<ecs>
yes, it's one of the two outputs that are opened by default on *nix
<dadepo[m]>
* I also find it strange that `stderr` seems to be used for something that is obviously not an error but log information :|
<ecs>
generally used for errors, debug logs, anything that doesn't want to go directly to the user
<ecs>
you can redirect it with 2>[file]
<dadepo[m]>
ok...I start ipfs by running `ipfs daemon` ... now I have it running...is the stderr part of the normal "log stream" I see? I mean if I do not do any redirection?
<ecs>
yes, it's sent to the pty by default
<ecs>
(the pty is usually your terminal emulator, but can be something different if you're using eg. ssh)
<dadepo[m]>
Ok...then I do not need to do anything special to see it's contents then...I thought what is sent to the pty by default is the stdout
<ecs>
both of them are sent to the pty by default, the details aren't important
Acacia has quit [Ping timeout: 260 seconds]
<dadepo[m]>
but now that I am talking about it...Ithink I have read somewhere in the past that both actually get sent to the pty by default
<ecs>
*aren't important for this topic
<ecs>
that is correct, and stderr is always unbuffered (stdout will be buffered if it's redirected to a file)
Pie-jacker875 has quit [Ping timeout: 260 seconds]
Pie-jacker875 has joined #ipfs
<dadepo[m]>
Thanks ecs for helping with the clarifications