Giters

lnurl / luds

lnurl specifications

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

lud-6 metadata still unclearly defined

michaelWuensch opened this issue · comments

commented

Hi there,
lud-6 metadata is still unclearly defined, even after the last update.
Would the following "nonArrayEntry", be allowed?

[
  "nonArrayEntry",
  [
    "text/plain",
    "HfnJxZojptcreqTXkWPLT w"
  ],
  [
    "application/payer-ids",
    [
      "text/plain"
    ],
    [
      "application/pubkey"
    ],
    [
      "text/identifier"
    ],
    [
      "text/email"
    ],
    [
      "application/lnurl-auth",
      false,
      "d394e8f300e30d9aba0a1e8fc48a92a2252cfa3b215c5421b888d6884036a59b"
    ]
  ]
]
commented

Yes, in everybody's minds it was assumed that adding any type of element to the metadata array wouldn't cause it to break.

But that has caused a ton of confusion and since I implemented it on lntxbot a bunch of people reported errors from wallets not understanding the new metadata and failing.

Turns out even the people involved in writing that new spec had their wallets broken by it, so big was the confusion, so we have been arguing on https://t.me/lnurl about how to change LUD-18 for better.

I guess you know that but I'm leaving this here for the posterity.

commented

yes, I know that. That argue lead to a more specific explanation on how the metadata should be.
All I say is this is still not specific enough. It still has the same issue one hierarchy higher, that the spec does not clearly define what is allowed and what isn't.

I think it would be good to make this completely specific now so we don't have another compatibility issue in the future.

commented

"nonArrayEntry",

No it wouldn't be allowed, LUD-06 assumes that the item inside the metadata array is an array. In other words a metadata entry is an array.
My latest change just specified what's allowed to be in that internal array.

I'm definitely for improving wording though and I strongly think that the items inside the metadata array has to be an array.

commented

I also think it shouldn't be allowed. If @fiatjaf thinks the same I will make a PR clarifing it.