As the modernization of the alias framework will allow STLDs, is necessary to make update on the specifications table:
https://github.com/signum-network/SIPs/blob/master/SIP/sip-44.md#specification

As we can appreciate in the alias field, the rule column shows an outdated one, it should be a regex expression that support STLDs

Testing the expression

Solution
The regex expression can be updated to the following:

^(\w+)(?:\.(\w+))?$

Testing the expression

Additional context
According to devina.io redos-checker
It states that the statement is safe

It seems that the row about CIP30 is missing!

Current changes were already made but they are not included in SIP:

Add extended API:
GET_CURRENT_BALANCE: gets the asset quantity for the asset id in B2 (or SIGNA if B2==0)
GET_TYPE_FOR_TX_IN_A = 0x0305: document the getType values (maybe part of SIP37?)

Add new API
GET_ASSET_CIRCULATING = 0x040f; // EXT_FUN_RET total circulating supply of tokens of asset ID in B2

Note: I do not know how to format for SIPS.

Request NFT: add tokens and SIGNA flow to owner.

1. During the NFT portal screen to add your graphic
   a) connected XT wallet would know what existing tokens the account has
   b) a drop down to show what tokens are selectable
   c) a box for how many tokens to include with NFT minting
2. Have code for the Minted NFT that when SIGNA lands in the smart contract address of the NFT that the new SIGNA gets sent to owner of the NFT.

This would be to take an existing token and include it with a unique NFT graphic that says how many tokens are included. And when the token sends out dividends then the NFT smart contract passes the received SIGNA to the NFT owner's SIGNA address.

Not sure about royalties or platform fees.

The table that lists all CIPs as an overview can be updated.

As a subscription platform, we should also consider showing the description and interval of expired/cancelled subscriptions
The current way to fetch expired/canceled subscriptions is by fetching the transactions with type=21 and subtype=4

As you can see on the response payload, the attachment property. description and interval is missing.

{
      "type": 21,
      "subtype": 4,
      "timestamp": 278363698,
      "deadline": 1440,
      "senderPublicKey": "7158e2e1170f9a3e1799ba4069ab55fac3d2242db5c0a08faf91c8b7cac3cb1f",
      "amountNQT": "0",
      "feeNQT": "2000000",
      "signature": "b3db293e1fe637feda63ad9229cb3d6fbfa3afb4b6f104dd2b1c90e0d093130378d8acc6f7add947cebbc669d24ffbd700909f506376529b1cc117ebeb0e1e7f",
      "signatureHash": "d5cc652417775a8ff35a9b9845b1b389eefeb9012684e2cc297c7a32cebb5a24",
      "fullHash": "db68ec363e0b6e2af925056151ae37da50c2a0d843652730dd035ead5c9dc56d",
      "transaction": "3057393558868486363",
      "attachment": {
        "version.SubscriptionCancel": 1,
        "subscriptionId": "10561777840324094517"
      },
   // ...Remaining Transaction objects
    }

It means the only way of getting the description and interval of canceled subscriptions is by making another getTransaction request.

Suggestion:
We can consider extending the attachment property

    "attachment": {
        "version.SubscriptionCancel": 1,
        "subscriptionId": "10561777840324094517",
        "subscriptionDescription": "SRC44 DESCRIPTION OF CANCELLED SUBSCRIPTION",
        "subscriptionInterval": "0000000",
     }

Benefits:

• Prevents unnecessary requests
• Save bandwidth

As recently proposed (and already running experimental implementation) in SIP50 it could be interesting to add a web socket communication for P2P communication. This FR does not provide any technical details yet,... but I will analyze how P2P works and check how to enhance the API using WS.

The motivation is similar to SIP50. We might expect a lightweight event driven full-duplex communication which should be usually favored over common request/response communication.

I propose that we expand the SRC-44 descriptor to include a new OPTIONAL property that refers to a "country code" in the description field structure.

The key would be labeled as ctry and the value would be just an ALPHA-2 Country code
https://www.iban.com/country-codes

These would be the properties

Adjust the fee for asset (token) issuance to 150000 * FEE_QUANT from 15000 * FEE_QUANT

Currently the token creation is being abused by bad actors with offensive names and illegal acts and sending them to people unsolicited. It wasn't abused before the token issuance fee was lowered.

This causes a bad name for SIGNUM. And will drive people away.

Here are some names and their creators, not all offensive but some are the same as real coins past and present.

Not sure what the one that starts with Y even means.

Hardfork is planned soon. I suggest that a more serious consideration be given to reducing the new block minting time from 4 minutes to 2 minutes.

Advantages and reasoning:

1. Increase in transaction speed. Right now the transaction speed is 16 TPS. Now there are blockchains, such as Solana, Fantom, Algorand etc, where transaction speed is thousands of transactions per second. The logic of Signum does not allow to achieve such speed. But, reducing the mining time will be able to increase the speed already by 32 TPS, which is very significant in a fast-growing project.
2. Now, to wait for the coins to get from the wallet to the wallet, user have to wait 4 minutes. Visa, PayPal, Solana do it almost instantly. Reducing the waiting time will make the network more user friendly.
3. When the project becomes popular, it will have to process thousands of transactions. Users will pay a large fee to have their transaction processed first. Accordingly, people who are not willing to pay a large commission will have to wait a very long time for their transaction to be added to the block. This could theoretically cause the same high gas problems as Ethereum has now.
4. Increase the speed of work with smart contracts. To confirm and start a smart-contract, programmer have to wait 2-3 blocks, that's 8-12 minutes. Reducing the block generation time make it 2 times faster without any losses.
5. Working with NFTs. When people upload 10k collections to signumart it can paralyze the blockchain at all, especially if 10 artists put 10k images to upload at a time. The more the marketplace grows, the more speed is needed to process all those NFTs.
6. GameFi. In the future Signum will be able to support smart contracts to create play-2-earn games. Players will get/create different attributes: swords, potions, lands, armor in the form of NFTs. If the game is dynamic, users will simply refuse to play it, knowing that they have to wait as long as 8 minutes to create one smart contract/make some on-chain action. Other slow blockchains are already facing this problem.
7. Benefit to Miners. Now the number of mined coins decreased to 100 (I did not notice the benefit in the gradual reduction, it did not affect the price of the coin). There are 36000 coins mined per day, that's only $108 for 1034 miners. This money is not enough for the average miner to even pay for electricity, not to mention the benefit of buying hard drives. Many miners (myself included) have already sold their hard drives. The capacity right now is only 26.3 PiB. If miners get twice the amount of coins per day it might encourage people to invest money in this business and thus increase the size of the commitment. If 72,000 coins will be mined per day, it will be only 0.0033% increase in capitalization. That is 1.2% per year. This will have no effect on inflation.

Please consider my proposal thoroughly before HardFork is launched.

I suggest that a more serious consideration be given to allowing token descriptions to be mutable.
As previously stated by ohager this is a protocol change.

Hope consider my suggestion thoroughly before a hard fork is launched.