<j​effro256:monero.social> Is there any character limit for DNS records or openalias we could run into?

<j​effro256:monero.social> Just asking since new Jamtis addresses will likely be 244 characters long

<a​js_:matrix.org> jeffro256: TXT record limited to 255 characters per string

<j​effro256:monero.social> TXT records don't have to actually contain human-readable data right? Is it an option to store addresses as raw bytes or that frowned upon in openalias?

<j​effro256:monero.social> Then Jamtis address as raw bytes is only 153 bytes

<j​effro256:monero.social> Also, can the key-value pairs appear in a different TXT record?

<a​js_:matrix.org> Has there been any work done on MoneroDNS?

<a​js_:matrix.org> IIRC, a few years ago there was talk about collaborating with Jeremy, dev from Namecoin

<j​effro256:monero.social> Sorry, I'm being loose with my terminology. Rather, does the OpenAlias spec care if the OpenAlias message with key/value pairs is spread across multiple strings within a TXT record with arbitrary breaks?

<j​effro256:monero.social> I've never heard of MoneroDNS

<a​js_:matrix.org> It was on the Monero roadmap of development back in 2016

<a​js_:matrix.org> Decentralized dns similar Namecoin’s .bit

<a​js_:matrix.org> web.archive.org/web/20170103072827/https://getmonero.org/design-goals

<a​js_:matrix.org> MoneroKon 2024 Submission Deadline - 2 weeks™ - Submit a proposal for talk/workshop before 15th March - apply.monerokon.org

C is now illegal. Byenance delists us. We're all doomed! whitehouse.gov/oncd/briefing-room/2…2/26/press-release-technical-report

ffs, keep to #monero with the non dev stuff.

<v​tnerd:monero.social> jeffro256: I brought up the TXT limits immediately in the OA2 chatroom, and was informed that it's possible to concatenate the records

<v​tnerd:monero.social> The limit per record is 255.

<v​tnerd:monero.social> And I think TXT records can contain anything, but as noted in the chatroom if we go for a more compact format, it requires a tool to be run to generate the record, whereas it can be done by hand right now

<v​tnerd:monero.social> Although if we are spanning multiple records, it may require a tool to do the split effectively anyway

<v​tnerd:monero.social> I suggest joint #openalias chatroom

<v​tnerd:monero.social> *joining

<j​effro256:monero.social> Done thanks

<j​effro256:monero.social> Yeah if the records can be concatenated, then it should definitely remain human readable since AFAICT mot DNS tools have human usable ways to make long DNS strings from my short 15 mins of research

<d​etherminal:matrix.org> bullish for cuprate

<s​omeoneelse495495:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/vvGyvblPEMBfnRSVNBVnINRh

<s​omeoneelse495495:matrix.org> why is the `fees` field in `get_fee_estimate` core rpc response not consistent

<s​omeoneelse495495:matrix.org> dont mind the change of ports, same behavior with or without restricted rpc

It's estimated from the current chain state, which changes.

<s​omeoneelse495495:matrix.org> So while it's changing it just disappear

<s​omeoneelse495495:matrix.org> So while it's changing it just disappear ?

<s​omeoneelse495495:matrix.org> Nevermind I realize I got the two possible rpc response, the one if `version >= HF_VERSION_2021_SCALING` and the else one (core_rpc_server.cpp). I still don't understand why tho since `get_current_hard_fork_version()` is `const`

Are you sure your daemon was not syncing old blocks when you got the < HF_VERSION_2021_SCALING version ?

<s​omeoneelse495495:matrix.org> I was indeed syncing... I thought it immediatly goes and check to the bootstrap daemon

It seems it does, from reading the source.

<s​omeoneelse495495:matrix.org> then it's weird. I shouldn't get the the pre 2021 response format