search

Ocelot-Social-Community / Ocelot-Social

Free and open-source social network for active citizenship.
https://ocelot.social
Other
95 stars 38 forks source link

Slugs - Permanent, unbreakable, readable and text changeable slugs for users, posts etc. #209

Open Tirokk opened 4 years ago

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

Is your feature request related to a problem? Please describe.

  1. An URL – a slug – should potentially last forever and do never break. (We do program for eternity!)
  2. The individual and human readable part of the slug should be changeable. Because real names can change and headlines of posts as well. And since the human readable part of the slug is important for SEO it should be changeable, because you may have typed wrong or your realise that another headline of a post will do much better or even violates rules etc.

Describe the solution you'd like A solution can be a combination of a unique ID for the user, post etc. followed by a human readable part, that can be changed by the user by changing their names or headlines etc.

As an example stackexchange.com uses them: https://webmasters.stackexchange.com/questions/113717/will-having-product-id-in-urls-hurt-seo-compared-to-a-url-with-only-keywords

So for HC it will look like: https://human-connection/profile/85739/peter-lustig https://human-connection/post/6976396/distinctio-amet-voluptate/

But there have to be some things considered closely !!! See later …

Describe alternatives you've considered An alternative could be to put the ID at the very end of the slug. https://human-connection/profile/peter-lustig/85739 But I read that this has the danger to be cut of by algorithms that truncate the URL after 80 chars as an example. And we would have to be aware to limit the headlines of posts somehow.

Additional context I have investigate this today more closely after my discussion about this with @roschaefer on Saturday.

If we do so …

  1. … we have do redirect 301 every URL that hits the right ID but does not match the human readable text part. Otherwise the SEO will decrease, because of duplicate URLs to the same content and loose the SEO of the first version.
  2. Every page has to have it’s unique URL as „rel=canonical“ meta tag. Here the readable text should be included, because otherwise this text will be excluded from the SEO by Google.

The ID may have an impact on the SEO as well. But with this the people are not really sure.

  1. On one hand the ID part counts as an additional „word“ of the URL which may lower the wait of the words in the readable text part.
  2. But on the other hand Google itself forces the news companies to put unique numbers at the articles URLs of their news feeds to avoid duplicated URLs to different content.
Tirokk commented 4 years ago

appinteractive Authored by appinteractive

I would go with some hashed uuid with some 6 chars or so.

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

You will say the benefit is something shorter?

But than the uniqueness is not safe and for me that is absolut necessary. Because it is important to use the link in the outer world !

Is the database ID to long? Than lets generate a shorter one that increases: 1, 2, 3, … … but unique.

Tirokk commented 4 years ago

appinteractive Authored by appinteractive

Never use numeric ids, ever as they do not scale at all. Our UUIDs in the other hand are 36 chars long, to long in my opinion for the links. Just save a short version to them and do a fallback an the slug?

Tirokk commented 4 years ago

roschaefer Authored by roschaefer

@appinteractive numeric ids don't scale, why?

Tirokk commented 4 years ago

appinteractive Authored by appinteractive

First, numeric values are always a security issue as they can be guessed and brute forces which might end up in unexpected behavior or attacks by script kiddies.

Also can it be problematic in situations where you have several servers running in parallel wanting to write at the same time producing the same ids. I read a good article by someone from eBay about issues they had with something like that. But that obviously depends on the database you are using.

In my opinion we should avoid numeric ids at all costs where not necessary.

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

There are the following important things to this kind of UUIDs in my eyes @appinteractive @roschaefer :

  1. Safety
  2. Uniqueness is kind of the main goal
  3. Shortness
  4. Readability of the slugs that can be changed
  5. SEO – if it's a number – no matter how we get to it – Google can distinguish between this kind of textual meaningless UUIDs and the readable SEO part of the slug. Therefore it seems better to me to have pure digits.
  6. UUID don’t have to be at the end of the slug

What is if we generate such UUIDs separately by a sole service which just counts – may it counts separately for each user, post etc. – and is not related to the database at all? The database just stores this UUIDs. Than it can be very quick and can not be related to safety issues with the database. Or I’ve been taken wrong?

If Twitter, stackoverflow etc. do it, there must be a save and good way …

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

I do not see either why numeric UUIDs don’t scale …

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

In our discussion @appinteractive had the solution to encode or to compress the UUID somehow to get a non numeric and short URL-ID:

Tirokk commented 4 years ago

appinteractive Authored by appinteractive

We could use nanoid instead of uuid for url friendly ids. https://github.com/ai/nanoid

Tirokk commented 4 years ago

appinteractive Authored by appinteractive

The other way is to compress our UUIDs for urls https://github.com/oculus42/short-uuid

Tirokk commented 4 years ago

stale[bot] Authored by stale[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

We should have micro-UUIDs or short-UUIDs in our URLs as standard. The long versions should be possible for compatibility.

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

Is the Additional context of the issue fulfilled in your eyes @roschaefer @mattwr18 ? I guess probably not everything, or?

I created an extra issue #2786 for the Short- / Nano-ID …

Tirokk commented 4 years ago

stale[bot] Authored by stale[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

Is not stale …

Tirokk commented 4 years ago

stale[bot] Authored by stale[bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Tirokk commented 4 years ago

Tirokk Authored by Tirokk

Is not stale …