stebalien changed the topic of #ipfs to: Heads Up: To talk, you need to register your nick! Announcements: go-ipfs 0.5.0-rc4 and js-ipfs 0.41 are out! Get them from dist.ipfs.io and npm respectively! | Also: #libp2p #ipfs-cluster #filecoin #ipfs-dev | IPFS, the InterPlanetary FileSystem: https://github.com/ipfs/ipfs | Logs: https://view.matrix.org/room/!yhqiEdqNjyPbxtUjzm:matrix.org/ | Forums: https://discuss.ipfs.io | Code of
cipres has quit [Ping timeout: 240 seconds]
se7en has joined #ipfs
jrt is now known as Guest37377
Guest37377 has quit [Killed (tolkien.freenode.net (Nickname regained by services))]
jrt has joined #ipfs
manufacturers has quit [Remote host closed the connection]
rams_ has joined #ipfs
Ecran has quit [Quit: Going offline, see ya! (www.adiirc.com)]
cobalt00 has quit [Remote host closed the connection]
tstock_007 has quit []
tstock_007 has joined #ipfs
mauz555 has quit [Remote host closed the connection]
tstock_007 has quit []
raucao has quit [Ping timeout: 260 seconds]
tstock_007 has joined #ipfs
raucao has joined #ipfs
dopplergange has quit [Ping timeout: 256 seconds]
Jeanne-Kamikaze has joined #ipfs
dopplergange has joined #ipfs
joocain2 has quit [Remote host closed the connection]
joocain2 has joined #ipfs
}ls{ has quit [Ping timeout: 260 seconds]
qwert25681mf[m] has joined #ipfs
}ls{ has joined #ipfs
basilgohar has quit [Quit: leaving]
fengdaolong has quit [Ping timeout: 240 seconds]
fengdaolong has joined #ipfs
xcm is now known as Guest51059
Guest51059 has quit [Killed (verne.freenode.net (Nickname regained by services))]
basilgohar has joined #ipfs
xcm has joined #ipfs
dwilliams has quit [Ping timeout: 260 seconds]
parker[m] has left #ipfs ["User left"]
cheet has quit [Read error: Connection reset by peer]
xelra has joined #ipfs
LarchOye1 has joined #ipfs
cheet has joined #ipfs
endvra has quit [Read error: Connection reset by peer]
endvra has joined #ipfs
xelra has quit [Remote host closed the connection]
ipfs-stackbot1 has quit [Remote host closed the connection]
ipfs-stackbot1 has joined #ipfs
bren2010 has quit [Ping timeout: 265 seconds]
bren2010_ has joined #ipfs
ylp has joined #ipfs
fazo96 has quit [Ping timeout: 246 seconds]
fazo96 has joined #ipfs
fazo96 has quit [Ping timeout: 260 seconds]
fazo96 has joined #ipfs
Taoki has joined #ipfs
endvra has quit [Read error: Connection reset by peer]
endvra has joined #ipfs
Ecran has quit [Ping timeout: 264 seconds]
bren2010_ has quit [Quit: l8r sk8rs]
bren2010 has joined #ipfs
jcea has joined #ipfs
KempfCreative has joined #ipfs
srinathgs has joined #ipfs
SmokedHamDiscord has joined #ipfs
<TraderOne[m]>
ipns in dnslink is really bad idea, its too slow to resolve and not always it resolves to newest copy.
lord| has quit [Read error: Connection reset by peer]
lord| has joined #ipfs
<rudolph9[m]>
<TraderOne[m] "ipns in dnslink is really bad id"> What are some way we could improve it?
LarchOye2 has quit [Remote host closed the connection]
RingtailedFox has joined #ipfs
jokoon has joined #ipfs
RingtailedFox has quit [Ping timeout: 240 seconds]
fabianhjr has joined #ipfs
srinathgs has quit [Quit: srinathgs]
<TraderOne[m]>
People are using ipns because they are lazy to deal with updates
<TraderOne[m]>
Only improvement possible is disallow ipns in dnslink
<aschmahmann[m]>
@trader_one:matrix.org: It sounds like your issue is with IPNS performance is general and not about the interaction between DNSLink and IPNS.
<aschmahmann[m]>
Two goods reasons to use them together are to either associate a nice name with your IPNS key instead of a hash. Another is if you have frequent updates then DNS will probably not update fast enough for you, and certainly won't update faster than IPNS over PubSub.
<aschmahmann[m]>
In terms of performance I totally hear you though. Go-ipfs 0.5.0 has some improvements to the IPNS over PubSub that should make it faster and more robust. Additionally, the DHT changes should improve IPNS publish and resolution speeds. Note that while the DHT should perform better upon release that much of the performance improvements to the network will come as more people upgrade to the latest version.
eater has joined #ipfs
jesse22 has quit [Ping timeout: 246 seconds]
jesse22 has joined #ipfs
ygrek has joined #ipfs
<Swedneck[m]>
<TraderOne[m] "Only improvement possible is dis"> that is a horrible idea
<Swedneck[m]>
fwiw i'm on go-ipfs v0.5.0-rc3 and ipns seems very fast now
abueide[m] has joined #ipfs
lordcirth has quit [Read error: Connection reset by peer]
bengates has quit [Remote host closed the connection]
joocain2 has quit [Remote host closed the connection]
joocain2 has joined #ipfs
<hsanjuan[m]>
aLeSD: yes, I think you can set the environmental variable `CLUSTER_IPFSHTTP_NODEMULTIADDRESS=/ip4/.....`
<hsanjuan[m]>
I thought this was more clearly documented somewhere but seems not
<abueide[m]>
can pinata pin an ipns directory? e.g. if i put a small markup blog will it pin updates?
<abueide[m]>
* can pinata pin an ipns directory? e.g. if i put a small hugo blog on it, will it pin updates?
dwilliams has quit [Ping timeout: 240 seconds]
<aLeSD>
hsanjuan[m] is there a pay to pass it by param to ipfs-cluster-follow ... I am using a container and it sees I can't set programatically the environment variable
dwilliams has joined #ipfs
<hsanjuan[m]>
aLeSD: no param for it. I find it very strange that you cannot pass environment variables to the container. Can you mount a custom configuration folder?
rendar has quit []
<aLeSD>
hsanjuan[m], I did it: but
<aLeSD>
error applying environment variables to configuration: error parsing ipfs_node_multiaddress: failed to parse multiaddr "/ip4/ipfs.node/tcp/5001": invalid value "ipfs.node" for protocol ip4: failed to parse ip4 addr: ipfs.node
<aLeSD>
hsanjuan[m], I am currenty using a custom docker... but is it possible to make the official ipfs-cluster image to run ipfs-cluster-follow instead of ipfs-cluster-service ?
Sajesajama__ has quit [Quit: Leaving]
<hsanjuan[m]>
aLeSD: not without a custom entrypoint. The binary is there though...
lordcirth has joined #ipfs
<lordcirth>
topic needs updating
<hsanjuan[m]>
might just publish an specific ipfs-cluster-follow container
ZaZ1 has joined #ipfs
ZaZ2 has joined #ipfs
ZaZ has quit [Ping timeout: 260 seconds]
<Swedneck[m]>
:OOO new release!!!
<lordcirth>
Indeed
ZaZ1 has quit [Ping timeout: 260 seconds]
<lordcirth>
Still trying to get it to build as a nix pkg
<aLeSD>
hsanjuan[m], I resolved: docker-compose has an entrypoint: entry
<lordcirth>
Something with the build chroot is breaking some paths
<Swedneck[m]>
i wish ipfs-update was available for arm64
<lordcirth>
blog.ipfs.io/2020-04-28-go-ipfs-0-5-0/ has a mistake; the infographic large print says 2X faster adding, the fine print says 25X. Which is correct? or are they comparing to different things?
kdlv has joined #ipfs
Trieste has joined #ipfs
<aschmahmann[m]>
The 2x speedup is how much faster the Badger datastore performs in 0.5.0 compared to previously (on an HDD, on SSDs it's even faster). This brings the overall speed comparison between flatfs and badger is now 25x.
<aschmahmann[m]>
* The 2x speedup is how much faster the Badger datastore performs in 0.5.0 compared to previously (on an HDD, 3x on SSDs). This brings the overall speed comparison between flatfs and badger is now 25x (for HDDs, and 32x for SSDs).
<lordcirth>
aschmahmann[m], I see. That's not at all clear, though
gimzmoe_ has joined #ipfs
nman has joined #ipfs
ni291187 has joined #ipfs
ni291187 has left #ipfs [#ipfs]
cruxeternus has joined #ipfs
KempfCreative has quit [Ping timeout: 246 seconds]
KempfCreative has joined #ipfs
RingtailedFox has joined #ipfs
gimzmoe_ has quit [Ping timeout: 240 seconds]
<Swedneck[m]>
hmm, i upgraded my server node to 0.5.0 but it still takes several seconds to resolve content that's available on the LAN
caskd has quit [Ping timeout: 260 seconds]
fabianhjr has joined #ipfs
fabianhjr has quit [Max SendQ exceeded]
fabianhjr has joined #ipfs
fabianhjr has quit [Max SendQ exceeded]
fabianhjr has joined #ipfs
fabianhjr has quit [Max SendQ exceeded]
fabianhjr has joined #ipfs
fabianhjr has quit [Max SendQ exceeded]
fabianhjr has joined #ipfs
gimzmoe_ has joined #ipfs
se7en has quit [Ping timeout: 244 seconds]
caskd has joined #ipfs
<aschmahmann[m]>
@swedneck:swedneck.xyz: what does available on the LAN mean? Do you have MDNS enabled, how do you find the peers on your LAN?
g2anj has quit [Ping timeout: 260 seconds]
g2anj has joined #ipfs
<Swedneck[m]>
MDNS is presumably whatever the default is, and i have my desktop's peer in the server's bootstrap list
<Swedneck[m]>
(i haven't really been able to find much info about MDNS online)
<Swedneck[m]>
ah, the config on the server says it's enabled, with interval 10
<Swedneck[m]>
same on desktop
ygrek has quit [Ping timeout: 260 seconds]
<aschmahmann[m]>
My understanding of the MDNS system is that you'll broadcast "hi I'm a libp2p node" and so everyone on your network will just end up connected to each other.
<aschmahmann[m]>
This means the DHT shouldn't even be involved in your lookup, because bitswap will ask the peers you're connected to is they happen to have the data aside from going to the DHT to find providers.
<aschmahmann[m]>
If your nodes are showing up in each other's `ipfs swarm peers` but resolving content is slow then that's concerning. Lmk if that's what's happening
<Swedneck[m]>
hmm, i think it's specifically IPNS resolution which is slow
<Swedneck[m]>
i just ran `ipfs ls /ipfs/QmTK3vprYQcAHySa6SHVzxX3cMmSznMzBpk66i4WaGMdGk` and it was instant on the server
<Swedneck[m]>
..even non-recursive dnslink resolution is slow
shrike_ has joined #ipfs
shrike_ has left #ipfs [#ipfs]
<aschmahmann[m]>
I'm not at my computer right now, but if you want fast IPNS resolution try enabling IPNS over PubSub (--enable-namesys-pubsub). If both nodes are v0.5.0 then it should resolve very quickly on a LAN.
<Swedneck[m]>
pretty sure that's already enabled
<Swedneck[m]>
yeah
<Swedneck[m]>
but it also has `--enable-pubsub-experiment`
<Swedneck[m]>
should i remove that one?
<aschmahmann[m]>
I don't think that should make a difference since namesys-pubsub should automatically set PubSub. Are the peers showing up in swarm connect?
dirdel has joined #ipfs
<Swedneck[m]>
oh yeah i have already made sure the server is connected to my desktop
<Swedneck[m]>
republishperiod is also empty on desktop
<RubenKelevra[m]>
Swedneck: additionally, do you use the records just on your lan? In this case you might want to switch to ipfs cluster instead to do the remote pinning/unpinning :)
<Swedneck[m]>
i don't want to store data on the server since it doesn't have enough storage
<Swedneck[m]>
i want to store the data on my desktop and use the server to serve data on https://download.swedneck.xyz and other sites
<RubenKelevra[m]>
Swedneck: try gossipsub as router and 15m as republish period. TTL is the time your record is not considered stale, while lifetime is the amount of time it's valid if there's nothing new.
<RubenKelevra[m]>
So TTL should be your 'refresh' time while lifetime should be set to something big, in case your node publishing has an outage. I use 96h.
<Swedneck[m]>
do i type literally `15m`?
<RubenKelevra[m]>
<Swedneck[m] "i don't want to store data on th"> Ah, this makes sense :)
<RubenKelevra[m]>
Swedneck: yes
<RubenKelevra[m]>
Swedneck: these are just the defaults, you can specify other values while you publish
<aschmahmann[m]>
@swedneck:swedneck.xyz: I'll check when I'm back at home to make sure no weird changes were introduced but if the peers are connected and you do an IPNS publish then resolving should be instant (both machines 0.5 with IPNS over PubSub enabled), and no DHT involvment required.
kn0rki has quit [Quit: Verlassend]
<RubenKelevra[m]>
aschmahmann (@aschmahmann:matrix.org): sure, but the side asking needs to have resolved the IPNS before, for this to work.
<Swedneck[m]>
oh, i tried resolving the actual ipns key and that is instant
<Swedneck[m]>
okay so i guess dnslink is the issue here
<aschmahmann[m]>
No it does not, per 0.5.0 changes
<RubenKelevra[m]>
Swedneck: try to resolve /ipns/pkg.pacman.store
<RubenKelevra[m]>
Strange, it's instantly for me, and the DNS service should be fast worldwide
<RubenKelevra[m]>
Swedneck: you're sure that you're not on the moon? 🤔
<Swedneck[m]>
yeah it's instant on my desktop
<Swedneck[m]>
for reference this is a rockpro64 running nextcloudpi
<aschmahmann[m]>
@rubenkelevra:matrix.org: btw that IPNS over PubSub change also makes it so that even when using the DHT for record discovery things will be faster since you just need to find a single peer to gain access to the topic instead of having to compete the DHT record lookup to find the latest record.
<Swedneck[m]>
`Download: 2.58 Mbit/s`
<Swedneck[m]>
***OH***
<RubenKelevra[m]>
<aschmahmann[m] "@rubenkelevra:matrix.org: btw th"> This explains why it's so much better since I use the pre rc1 master :)
<Swedneck[m]>
what
<RubenKelevra[m]>
<Swedneck[m] "for reference this is a rockpro6"> So you're using this device on the same internet connection as your desktop?
<RubenKelevra[m]>
Can someone confirm that Matrix is extremely slow? Like 30-60 seconds to publish a message?
<Swedneck[m]>
<RubenKelevra[m] "So you're using this device on t"> yeah, both are connected to the same router, both via ethernet cable
<Swedneck[m]>
<RubenKelevra[m] "Can someone confirm that Matrix "> matrix.org is absurdly overloaded, try signing up on feneas.org or some other server
<Swedneck[m]>
(or selfhosting)
<RubenKelevra[m]>
<Swedneck[m] "yeah, both are connected to the "> Alright. Interesting
<RubenKelevra[m]>
<Swedneck[m] "matrix.org is absurdly overloade"> I have a feneas account, but haven't set it up yet.
<RubenKelevra[m]>
Swedneck: I can't really help with your issue, have been a long while since I've used an arm64 with Linux.
<RubenKelevra[m]>
Just the regular stuff: Deactivate firewalls, deactivate security stuff like selinux, disable all non-essential services and try again.
<RubenKelevra[m]>
<Swedneck[m] "> <@rubenkelevra:matrix.org> I h"> Will do, but tomorrow. I'm tired :)
dethos has joined #ipfs
ygrek has joined #ipfs
KempfCreative has quit [Ping timeout: 264 seconds]
fazo96 has quit [Ping timeout: 246 seconds]
<aschmahmann[m]>
Swedneck is the result here that you're running into DNSLink resolution delays, but IPNS + IPFS are working fine?
<aschmahmann[m]>
On my machine DNS dig (and ipfs DNSLink) resolution takes in the <100ms range. Since you say dig is taking 2 seconds there's probably something else going on with your machine, although it's a bit concerning that DNSLink resolution takes so much longer than dig for you, is this new? Does your machine historically have slow dig times?
Ringtailed-Fox has joined #ipfs
<Swedneck[m]>
i think the server might just be absolutely wack
<aschmahmann[m]>
k, gl 😬
RingtailedFox has quit [Ping timeout: 244 seconds]
<Swedneck[m]>
rip, a guy in the pine64 chat tried to help but couldn't figure it out
mowcat has quit [Remote host closed the connection]
manray has quit [Ping timeout: 260 seconds]
millysoose[m] has joined #ipfs
<millysoose[m]>
Congrats on the new release. Waiting for it to hit Arch Linux!
<tstock_007>
I'm really excited about the IPFS concept and have been trying to "break in" for a while. Just been so busy with everything else that's going on in IT
<tstock_007>
Are there a few things that are especially exciting on the latest release?
dwilliams has quit [Ping timeout: 240 seconds]
joeyh has joined #ipfs
endvra has quit [Read error: Connection reset by peer]
endvra has joined #ipfs
pecastro has quit [Ping timeout: 260 seconds]
is_null has quit [Ping timeout: 240 seconds]
cipres has quit [Ping timeout: 256 seconds]
manray has joined #ipfs
ipfs-stackbot1 has quit [Remote host closed the connection]