Riccardo Spagni [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-27 📝 Original message:There are several reasons ...
📅 Original date posted:2015-07-27
📝 Original message:There are several reasons why we rejected doing it this way with OpenAlias:
1. It adds complexity for the alias creator. This may seem
unimportant, but the OpenAlias standard was created to empower people
to create their own aliases as simply as possible, not to make it
overly complex.
2. It's harder to mess things up by dropping a sub-record; you either
have the complete, valid record, or you don't. With a "tiered" system
you can claim that you support a particular alias, but then lack all
or some of the records for it.
3. You retain both forward and backwards compatibility (no need to
introduce a new OA version unnecessarily), as you can have an "old" KV
pair and a "new" KV pair within the same record. The addition of KV
pairs doesn't require the application to know the new pairs exist,
which makes it more extensible.
4. Even better - since an application gets the whole record it can
start off with a minimum viable product that merely gets the address,
and then at a later stage when support is added for additional
metadata *it already has the metadata* and can interpret it.
5. You can still do DNS delegation (proper, SOA delegation) or you can
do delegation via a KV pair of some sort (say, a reroute= pair or
something). In both cases delegation requires an additional lookup, so
there's nothing saved or improved with the two-tier system.
In this instance, as in many others, simplicity trumps complexity, and
the bonus is that the simpler solution is more extensible and
flexible.
Riccardo
> Thinking about it, I think that it would be better to separate those two
> operations: on one hand, the listing of TXT records under a name, and on
> the other hand, the possibility to use Zone Delegation.
>
> For example, let us use the "_oa2" name (Openalias version 2) when we
> need to introduce an intermediate level, and "_oa2_keys" for key listing.
>
> Here is an example:
>
> _oa2_keys.sample 3600 IN TXT "btc ltc email fullname"
> _btc.sample 3600 IN TXT "bitcoinaddress"
> _ltc.sample 3600 IN TXT "litecoinaddress"
> _btc.sample 3600 IN TXT "otherbitcoinaddress"
> _email.sample 3600 IN TXT "john.smith at googlemail.com"
> _fullname.sample 3600 IN TXT "John Smith"
>
> Zone Delegation: Let us assume example.com wants to delegate all its
> Bitcoin aliases to Netki. We introduce an intermediate level, with the
> "_oa2" name. In the alias, this string is translated as "@"
>
> john._oa2.example.com <-- will be looked up as john at example.com
> _btc.john._oa2.example.com <-- bitcoin address of john at example.com
Published at
2023-06-07 15:42:17Event JSON
{
"id": "b906881deda9b8dfe4f78b19c8674de10195c45067c9b23cb916822da7f9f0e0",
"pubkey": "fada22460acfa5561480a4bf88a43b3c166bb0cbbda01f3099de15f2290f26fa",
"created_at": 1686152537,
"kind": 1,
"tags": [
[
"e",
"2b792280c7c77e1a9146c50dbbc2a8f3336e57397d73b26f225d7fe35c48cd85",
"",
"root"
],
[
"e",
"4858fa0c72151baf3af33de59d29f6933629472c481add49c9e6213cde310ba1",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-07-27\n📝 Original message:There are several reasons why we rejected doing it this way with OpenAlias:\n\n1. It adds complexity for the alias creator. This may seem\nunimportant, but the OpenAlias standard was created to empower people\nto create their own aliases as simply as possible, not to make it\noverly complex.\n\n2. It's harder to mess things up by dropping a sub-record; you either\nhave the complete, valid record, or you don't. With a \"tiered\" system\nyou can claim that you support a particular alias, but then lack all\nor some of the records for it.\n\n3. You retain both forward and backwards compatibility (no need to\nintroduce a new OA version unnecessarily), as you can have an \"old\" KV\npair and a \"new\" KV pair within the same record. The addition of KV\npairs doesn't require the application to know the new pairs exist,\nwhich makes it more extensible.\n\n4. Even better - since an application gets the whole record it can\nstart off with a minimum viable product that merely gets the address,\nand then at a later stage when support is added for additional\nmetadata *it already has the metadata* and can interpret it.\n\n5. You can still do DNS delegation (proper, SOA delegation) or you can\ndo delegation via a KV pair of some sort (say, a reroute= pair or\nsomething). In both cases delegation requires an additional lookup, so\nthere's nothing saved or improved with the two-tier system.\n\nIn this instance, as in many others, simplicity trumps complexity, and\nthe bonus is that the simpler solution is more extensible and\nflexible.\n\nRiccardo\n\n\u003e Thinking about it, I think that it would be better to separate those two\n\u003e operations: on one hand, the listing of TXT records under a name, and on\n\u003e the other hand, the possibility to use Zone Delegation.\n\u003e\n\u003e For example, let us use the \"_oa2\" name (Openalias version 2) when we\n\u003e need to introduce an intermediate level, and \"_oa2_keys\" for key listing.\n\u003e\n\u003e Here is an example:\n\u003e\n\u003e _oa2_keys.sample 3600 IN TXT \"btc ltc email fullname\"\n\u003e _btc.sample 3600 IN TXT \"bitcoinaddress\"\n\u003e _ltc.sample 3600 IN TXT \"litecoinaddress\"\n\u003e _btc.sample 3600 IN TXT \"otherbitcoinaddress\"\n\u003e _email.sample 3600 IN TXT \"john.smith at googlemail.com\"\n\u003e _fullname.sample 3600 IN TXT \"John Smith\"\n\u003e\n\u003e Zone Delegation: Let us assume example.com wants to delegate all its\n\u003e Bitcoin aliases to Netki. We introduce an intermediate level, with the\n\u003e \"_oa2\" name. In the alias, this string is translated as \"@\"\n\u003e\n\u003e john._oa2.example.com \u003c-- will be looked up as john at example.com\n\u003e _btc.john._oa2.example.com \u003c-- bitcoin address of john at example.com",
"sig": "69fb9dafb3f2fcc38774fa667774002dc96e8d8fa12b261beeefc99982500b8aca6e48f503a913b296dc515bfc3861bca1acdf059eb56b1c76d39bc52d1b80a5"
}