<curious_>
Good day everyone, quick question, in order to publish a IPNS namespace, does a node need to have the keypair available locally?
<JCaesar>
I think yes. There was a suggestion that it should be possible to sign the publication offline and distribute it to other nodes, e.g. in case of a DDoS, but I don't think that is possible yet.
<curious_>
Basically, if I have a public IPFS gateway that also has the possibility to publish different IPNS records, does that gateway have to store all associated keys? Or can an architecture be devised where those keys can be on the client, and some passive crypto can be employed.
<r0kk3rz>
that gets tricky, because then you have to do revocation things
<JCaesar>
curious_: Hm, maybe you could get those clients to only connect to the gateway?
<curious_>
So basically if you want to publish to IPNS and preserve control over the record (in form of the key) in a self sovereign manner, you must run your node and you can not trust any public gateway to do it for you.
newhouse has quit [Read error: Connection reset by peer]
<JCaesar>
I mean, unless you want to give away your private keys…
<curious_>
JCaesar: right, that was my concern. Hmm, thank you for the help!
<JCaesar>
(I'm not an expert on these matters, btw.)
dimitarvp` has joined #ipfs
<r0kk3rz>
yeah it might be worth investigating alternative solutions, IPNS just links a signed record to a hash
<r0kk3rz>
i think ive seen some people use blockchains for that kind of thing
<JCaesar>
You're thinking about having a public gateway with, e.g. a writeable API and the possibility to just go POST /api/v0/name/publish/QmPublicHash <<<"---BEGIN IPFS SIGNED IPNS---…"?
markedfinesse has quit [Quit: Ping timeout (120 seconds)]
<curious_>
Right, I was thinking of alternative solutions, can be done on top of Ethereum for example, it's just I'm trying to make it as cheap as possible, if you have a volatile record, and need to update the Ethereum smart contract every time it changes, it can get costly or annoying.
<JCaesar>
(honestly speaking, I'm no fan of IPNS anyway. It's simply not quick enough. dns txtlink records are just so much more snappy.)
}ls{ has quit [Read error: Connection reset by peer]
<curious_>
JCaesar: Yeah, something along those lines. A post to register and a signature appended (or whatever passive cryptographic interaction is needed)
<r0kk3rz>
IPNS isnt great for volatile records either really
dimitarvp has quit [Ping timeout: 248 seconds]
<curious_>
And regarding the speed, the resolutions I've tried take anywhere between 10 - 120 seconds, depending on how the stars align :D Do you happen to know what the average / median time happens to be?
<curious_>
r0kk3rz: because of the time it takes to register / resolve them?
<r0kk3rz>
yeah
<curious_>
r0kk3rz: I see, by volatile I assume 2 - 5 changes a day
<curious_>
Perhaps that's not really that volatile
<curious_>
But yeah, the registration / resolution seems to be an issue, especially if you need to resolve them fast, ad hoc.
<r0kk3rz>
depending on your usecase you could do signed messages over pubsub
Taoki has joined #ipfs
dimitarvp` is now known as dimitarvp
<curious_>
r0kk3rz: haven't looked at pubsub in much detail yet, I will now, is that more or less stable / reliable? Or is it still very much work in progress?
<curious_>
And also do public gateways expose any APIs for interacting with pubsubs? Or do they only expose the add / cat functions?
<r0kk3rz>
its still a work in progress i think, and certainly not 'reliable' as such :)
<r0kk3rz>
but i see no reason why you couldnt make a pubsub topic with the same IPNS and pump it with updates
}ls{ has joined #ipfs
<JCaesar>
r0kk3rz: I think that exists. There's also some WIP way to follow IPNS records.
chowie has joined #ipfs
markedfinesse has joined #ipfs
Encrypt has joined #ipfs
<curious_>
Looking at pubsub now, a quick question, there is no way for a peer that has just subscribed to the topic to get the previous messages, correct?
<curious_>
There is no way to pin a message to the topic either, right? Basically looking for a way for a new peer that just subscribed to get some data right away (e.g. a hash), the only thing that comes to mind is broadcasting it periodically constantly.
<curious_>
Actually nvm, I think I can just see when a new peer joins and send it to them right away.
<r0kk3rz>
orbit-db is also a higher order constuction on those ideas
<r0kk3rz>
iirc these days it even does permissions
<curious_>
Interesting, so I don't have to reinvent the wheel, will look at that. Thank you for the help!
chowie has quit [Ping timeout: 276 seconds]
lidel has joined #ipfs
colatkinson has joined #ipfs
saki has joined #ipfs
colatkinson has quit [Quit: colatkinson]
jayemar has joined #ipfs
curious_ has quit [Quit: Page closed]
ccii has quit [Remote host closed the connection]
ccii has joined #ipfs
ONI_Ghost has joined #ipfs
ONI_Ghost has quit [Read error: Connection reset by peer]
maxzor has joined #ipfs
Mateon3 has joined #ipfs
Mateon1 has quit [Ping timeout: 240 seconds]
Mateon3 is now known as Mateon1
anewuser has joined #ipfs
jayemar has quit [Quit: ERC (IRC client for Emacs 25.3.1)]
droman has joined #ipfs
vivus has joined #ipfs
curious1234567 has joined #ipfs
nha has joined #ipfs
<cipres>
on linux with sata disks what would be the ideal filesystem to use for (rather) large IPFS repositories ?
Ecran has joined #ipfs
<Aranjedeath>
what is "rather large" what order of magnitude
<Aranjedeath>
ZFS will be good for data integrity, XFS for speed or Extremely Large™ (or both). Unsure if ext4 has resolved its scaling issues yet
<Aranjedeath>
rhel 7 defaults to XFS, for what it's worth. safe choice
Reinhilde is now known as Ellenor
plexigras has quit [Ping timeout: 240 seconds]
randomstrangerb has quit [Ping timeout: 240 seconds]
randomstrangerb has joined #ipfs
plexigras has joined #ipfs
<cipres>
Aranjedeath: ok thanks a lot. i'd like to dedicate around 2TB for these repos, i'll start with ext4
Encrypt has quit [Quit: Quit]
plexigras has quit [Ping timeout: 265 seconds]
plexigras has joined #ipfs
<curious1234567>
As far as I've seen most public IPFS gateways don't expose http endpoints related to pubsub functionality, is that right, or am I missing something?
<AphelionZ>
curious1234567: i think thats accurate. Its generally discouraged to open up the https endpoints to the public
<Icefoz>
curious1234567: pubsub is currently experimental, so, probably.
muvlon has joined #ipfs
<curious1234567>
Makes sense, thanks
<r0kk3rz>
if you want to use something like pubsub in the browser, you should be using js-ipfs anyway
<curious1234567>
r0kk3rz: I was thinking using it from a mobile device
<curious1234567>
But it seems for that I would have to run a gateway and use HTTP requets from the phone to the gateway.
muvlon has quit [Quit: Leaving]
<r0kk3rz>
maybe not, theres a combination of things i meant to try but then forgot
<r0kk3rz>
if your mobile devices can run a go-ipfs node that is
<curious1234567>
I assume that's not a lightweight process, right? :D
<r0kk3rz>
theres client mode, which doesnt serve DHT requests, which should make it a bit less chatty
<r0kk3rz>
and theres also circuit relay, in which a node can forward your requests
saki has quit [Ping timeout: 256 seconds]
saki has joined #ipfs
<r0kk3rz>
otherwise yeah, you'll have to have some kind of a http api you can connect to
<curious1234567>
Do you happen to know if the JS-IPFS lib allows for enabling some of these experimental features (e.g. the equiv. of --routing=dhtclient in go-ipfs)
<curious1234567>
When starting up a node.
<r0kk3rz>
im not sure, typically experimental stuff goes into the go implementation first
<curious1234567>
Makes sense, doesn't seem like it's documented in the repo, so I assume it's not there yet, will dig around.
randomstrangerb has quit [Ping timeout: 256 seconds]
randomstrangerb has joined #ipfs
<curious1234567>
Ahh, nvm, looks like it is supported