DEV Community: Samy

The Bits Inside a MAC Address (and What They Actually Tell You)

Samy — Wed, 26 Aug 2026 04:35:26 +0000

A MAC address looks like a random string of hex pairs, but it's not random at all. Every byte is doing a specific job, and once you know how to read them, a MAC address will tell you a surprising amount: who made the hardware, whether the address is even real, and how your OS derives an IPv6 address from it. Here's the breakdown, with a bit of Python to make it concrete.

The 48 bits

A MAC address is 6 bytes (48 bits), usually written as 6 hex pairs: 00:03:93:AB:12:34. It splits into two halves:

Bytes 1-3 (the OUI): assigned by the IEEE Registration Authority to a specific organization
Bytes 4-6: assigned by that organization to a specific device, however it wants

That's the theory, anyway. The two low-order bits of the very first byte break that clean split, and they're the most useful bits in the whole address.

The two bits that matter

Look at the first byte in binary. The two least significant bits are flags, not part of any vendor identifier:

I/G bit (bit 0): 0 means unicast (one device), 1 means multicast (a group)
U/L bit (bit 1): 0 means universally administered (globally unique, IEEE-assigned), 1 means locally administered (made up on the spot, not guaranteed unique)

In Python:

def mac_flags(mac: str) -> dict:
    first_byte = int(mac.split(":")[0], 16)
    return {
        "unicast": not bool(first_byte & 0b0000_0001),
        "universally_administered": not bool(first_byte & 0b0000_0010),
    }

mac_flags("00:03:93:AB:12:34")
# {'unicast': True, 'universally_administered': True}

If the U/L bit is set, don't bother looking up the OUI. There's no vendor to find. The address was generated locally, not assigned by the IEEE.

OUI, MA-M, MA-S, IAB, CID: the registry blocks

"OUI" is the term everyone uses, but the IEEE Registration Authority actually issues five different kinds of blocks, and they matter if you're trying to figure out how big or how new a registration is:

MA-L (MAC Address Block Large, the classic OUI): a 24-bit prefix, 16,777,216 addresses
MA-M (Medium): a 28-bit prefix, 1,048,576 addresses
MA-S (Small, replaced the old OUI-36): a 36-bit prefix, 4,096 addresses
IAB (Individual Address Block): deprecated in 2014, replaced by MA-S, but still shows up in old hardware
CID (Company ID): same registry, same format, but explicitly not for building MAC addresses, used for protocol identifiers instead

A vendor with a single IoT product line will often hold an MA-S block instead of a full MA-L, because 4,096 addresses is plenty and it's cheaper to register. If a lookup tool just says "OUI" for everything, you're losing that signal.

Randomization broke the "MAC = device" assumption

For a long time, "look up the OUI" was a reasonable way to answer "what kind of device is this." Then iOS 14, and most modern Android and desktop Wi-Fi stacks, started randomizing the MAC address per network (and sometimes per connection), specifically to stop this kind of tracking.

A randomized address almost always has the U/L bit set, which is exactly the bit from the flags above. So the same one-bit check that tells you "this isn't a registered vendor address" is also your best signal that you're looking at a randomized address, not a spoofed or malformed one. It's not a certainty (some real hardware legitimately uses locally administered addresses too), but it's a solid prior.

Deriving an EUI-64 / IPv6 link-local address

If you've ever wondered how an interface without DHCPv6 still gets an IPv6 address, this is how, at least under SLAAC with the (now largely deprecated but still common) modified EUI-64 method:

Split the 48-bit MAC into two 24-bit halves
Insert FFFE between them, making it 64 bits
Flip the U/L bit of the first byte

00:03:93:AB:12:34
to 00:03:93:FF:FE:AB:12:34   (insert FFFE)
to 02:03:93:FF:FE:AB:12:34   (flip the U/L bit: 0x00 to 0x02)

That becomes the interface identifier, appended to fe80::/64:

fe80::0203:93ff:feab:1234

Same input, same deterministic output, every time. That's also exactly why privacy extensions (RFC 4941) exist: a stable EUI-64-derived address is as trackable as the MAC it came from.

Putting it together

None of this requires a database. U/L bit, I/G bit, and EUI-64 derivation are pure bit math, no registry lookup needed. Where you do need a database is the vendor name itself, and that part changes: the IEEE adds and reassigns blocks continuously, so a hardcoded vendor table goes stale. For quick one-offs I usually just query a synced OUI database (I've been using macadress.com's API for this) rather than maintaining my own copy of the registry.

If you want to try the bit math yourself, any MAC address will do, even a locally administered one will confirm the flags are working correctly, since it'll come back "not universally administered" instead of throwing a vendor name at you.

Build a Daily Tech-News Bot for Slack or Discord in 15 Minutes (Node.js + NewTqnia API)

Samy — Mon, 17 Aug 2026 19:29:49 +0000

Every team I've been on has a #general channel that goes quiet by 11am. A daily digest bot is the easiest way to give people a reason to glance back at it, and "today's tech headlines" is a low-effort, high-signal thing to post that nobody minds seeing every morning.

Here's a complete Slack/Discord bot, built on NewTqnia's free public news API, that you can have running in about 15 minutes.

What we're building

A small Node script that:

Fetches today's tech headlines (AI, robotics, space, health, energy, and a few other beats) from NewTqnia's API
Formats them as a Slack or Discord message
Posts them to a webhook
Runs on a schedule via GitHub Actions, so there's no server to keep alive

Step 1: Install the SDK

npm install newtqnia-node

It's a small, typed client around NewTqnia's REST API. No API key is required for this.

Step 2: The script

// digest-bot.mjs
import { NewTqniaClient } from "newtqnia-node";

const client = new NewTqniaClient({ application: "tech-news-digest-bot" });

async function getDigest(locale = "en", limit = 5) {
  // "today" can be empty early in the day (it resets on the Asia/Dubai
  // boundary), so fall back to "latest" if there's nothing yet.
  const today = await client.news.today({ locale, limit });
  if (today.articles.length) return today;
  return client.news.latest({ locale, limit });
}

function toDiscordPayload(digest) {
  const lines = digest.articles
    .map((a) => `• [${a.title}](${a.url})`)
    .join("\n");
  return {
    content: `**Today in Tech, via [NewTqnia](${digest.publisher.url})**\n\n${lines}`,
  };
}

function toSlackPayload(digest) {
  const lines = digest.articles
    .map((a) => `• <${a.url}|${a.title}>`)
    .join("\n");
  return {
    text: `*Today in Tech, via <${digest.publisher.url}|NewTqnia>*\n\n${lines}`,
  };
}

async function postDigest(webhookUrl, kind = "discord", locale = "en") {
  const digest = await getDigest(locale);
  const payload = kind === "slack" ? toSlackPayload(digest) : toDiscordPayload(digest);

  const res = await fetch(webhookUrl, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload),
  });

  if (!res.ok) {
    throw new Error(`Webhook post failed: ${res.status} ${await res.text()}`);
  }
}

const webhookUrl = process.env.DISCORD_WEBHOOK_URL || process.env.SLACK_WEBHOOK_URL;
const kind = process.env.SLACK_WEBHOOK_URL ? "slack" : "discord";

if (!webhookUrl) {
  console.error("Set DISCORD_WEBHOOK_URL or SLACK_WEBHOOK_URL");
  process.exit(1);
}

postDigest(webhookUrl, kind).catch((err) => {
  console.error(err);
  process.exit(1);
});

A couple of things worth calling out:

today vs latest: NewTqnia's today endpoint resets on the Asia/Dubai day boundary and can legitimately return an empty array if nothing's published yet when your job runs. Falling back to latest avoids posting an empty digest.
Attribution: NewTqnia's API terms ask that you keep a visible link back when you display its content and preserve the article URLs it returns. Both formatters above do that by linking the publisher name, so you get this right by default rather than as an afterthought.

Step 3: Get a webhook URL

Discord: Server Settings > Integrations > Webhooks > New Webhook > copy the URL.

Slack: create an Incoming Webhook for the channel you want and copy the URL it gives you.

Test locally:

DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/..." node digest-bot.mjs

Step 4: Run it on a schedule, for free

No server needed. A scheduled GitHub Action does the job:

# .github/workflows/digest.yml
name: Post daily tech digest
on:
  schedule:
    - cron: "0 6 * * *" # 06:00 UTC daily, adjust to your team's morning
  workflow_dispatch: {}

jobs:
  post:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install newtqnia-node
      - run: node digest-bot.mjs
        env:
          DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}

Add DISCORD_WEBHOOK_URL (or SLACK_WEBHOOK_URL) as a repo secret, push, and you're done. workflow_dispatch is there so you can trigger a test run by hand from the Actions tab instead of waiting for the cron.

Where to take it from here

Filter by beat with category (e.g. client.news.today({ category: "artificial-intelligence" })) if your team only wants AI news, not space and health too.
Post in Arabic by passing locale: "ar". The API and SDK are bilingual by default.
If you'd rather not run a script at all, NewTqnia also has a drop-in embeddable widget for putting the same feed directly on a webpage instead of a chat channel.

Full API reference and the PHP SDK are on the developer page if you want to build something more involved than a digest bot.

Add Live Bilingual Tech News to Your Portfolio Site in One Line

Samy — Sun, 02 Aug 2026 20:46:41 +0000

Every portfolio site has the same problem: it's static. A grid of projects, a bio, a contact form — nothing on the page ever changes, which means nothing on the page proves you can work with live data. Recruiters and reviewers skim past it because there's nothing to skim.

The fastest fix isn't building your own API — it's embedding someone else's, and picking one that's actually interesting to look at. Here's how to drop a live, auto-updating tech news feed into any site with a single script tag, using NewTqnia, a bilingual (English/Arabic) tech newsroom with a free embeddable widget.

Why this is a good portfolio move, not just decoration

A static "About Me" page tells someone you can write HTML. A page with a live-updating feed tells them you can integrate a third-party service, handle async content, and think about internationalization (this one supports English and Arabic out of the box) — all real, hireable skills, for the cost of one script tag.

Step 1: Build your embed

Go to newtqnia.com/en/widget. It's a live configurator, not a docs page — every option you touch updates a preview instantly:

Content: custom heading, number of articles, language (English or Arabic), category filter (Artificial Intelligence, Robotics, Space, Health, and others), and ordering (latest first or most popular)
Appearance: card / list / compact layout, horizontal or vertical orientation, light / dark / automatic theme, accent color, and toggles for images and summaries Pick settings that match your site — a compact, dark-themed, "Artificial Intelligence"-filtered list looks noticeably more intentional than the default.

Step 2: Copy the generated snippet

Once you're happy with the preview, the page generates a ready-to-paste embed code block for you — copy it as-is. It'll look roughly like a single <script> tag referencing your chosen configuration, something like:

<script
  src="https://newtqnia.com/embed/widget.js"
  data-lang="en"
  data-category="artificial-intelligence"
  data-count="5"
  data-theme="dark"
  async
></script>

(Use the exact snippet the configurator gives you — it encodes the specific options you picked, so don't hand-type this one from memory.)

Step 3: Drop it into your site

Paste the snippet wherever you want the feed to appear — a sidebar, a footer section, a dedicated "Now Reading" panel on your homepage. The widget renders inside an isolated Shadow DOM, so it won't inherit or clash with your site's existing CSS, and it won't leak its own styles back into your page either. That's one less thing to debug.

One thing to check if your site enforces a Content Security Policy: you'll need to allow newtqnia.com for script-src, connect-src, and img-src, or the widget will silently fail to load.

Step 4: Make it yours

A few ways to push this past "I copied a script tag":

Toggle the language dynamically. Add a small button on your page that swaps data-lang between en and ar and re-mounts the widget — a tiny but real demonstration of handling i18n on the client.
Match it to your site's theme. If you already have a dark-mode toggle, wire it to the widget's theme option so the feed switches with the rest of the page.
Filter by what you're into. If your portfolio is robotics-focused, filter the widget to the Robotics category instead of leaving it on "All categories" — small detail, but it shows you're not just pasting boilerplate. ## Want to go further than the widget?

NewTqnia also ships a public REST API with an OpenAPI 3.1 spec, official PHP and Node SDKs, and an MCP server for AI agents — worth a look at newtqnia.com/en/developers if you'd rather build your own feed UI from scratch instead of using the pre-built widget. That's a meaningfully bigger project, but a great follow-up once the one-line version is live.

Either way, it's a five-minute change that turns a static portfolio into one with something actually happening on it.

I Built a News API Before I Had Users. Here's What I'm Learning.

Samy — Fri, 24 Jul 2026 04:44:01 +0000

The API went live on a Tuesday. I had no idea who would use it.

I was building NewTqnia, a bilingual technology publication in English and Arabic, and the requirements kept expanding. Website, RSS, JSON API, embeddable widget, browser new-tab page, structured timelines—each one wanted the same content delivered differently.

That raised a question I still don’t have a clean answer to:

How do you support six delivery surfaces without building six disconnected products?

This is not a success story. It’s a set of tradeoffs, some working, some questionable, and a few I’m actively looking to undo.

The API: small on purpose

The first public version of the Daily Digest API does almost nothing.

curl "https://newtqnia.com/v1/news/today?locale=en&limit=5"

That’s it. today, latest, two query params, no API key. Sixty requests per minute, ETag support, sensible Cache-Control.

I could have shipped categories, tags, search, recommendations, and analytics endpoints on day one. But a large API with unstable contracts is just a private API that happens to have public documentation. I wanted the opposite: a small surface that would not embarrass me if someone actually built against it.

The awkward part? Developers can’t ask for endpoints they don’t know are possible. So “wait for demand” is a safe strategy, but maybe not the right one. I’m still figuring out where the line is between “prudently small” and “uselessly small.”

The widget problem: isolation is expensive

Some people just want headlines on their site without writing HTTP clients. So I built a script:

<script
  async
  src="https://newtqnia.com/news-widget.js"
  data-count="5"
  data-locale="en"
  data-layout="cards"
  data-orientation="horizontal"
  data-theme="auto"
  data-accent="#03c0f9"
  data-order="latest"
  data-show-image="true"
  data-show-summary="true">
</script>

The widget builder generates this and shows a live preview.

Here is the part nobody warned me about: every isolation strategy moves complexity somewhere else.

Iframe? Strong style isolation, but responsive sizing becomes a negotiation with the host page.
Shadow DOM? Protects against CSS leaks, but theming and accessibility traversal get weird.
Plain script with scoped CSS? Familiar to embedders, but one !important rule on the host side and your layout collapses.

I went with the simple script and data-* attributes for now. I’m not convinced it’s the long-term answer. If you’ve shipped an embeddable widget, I’d genuinely like to know: did you regret not using Web Components from the start?

Timelines are not articles

A news article describes a moment. A timeline has to explain how moments relate across years.

We publish timelines on things like the evolution of generative AI and the history of the Internet. Internally, these are not long articles. They are collections of events with fields like:

Exact or approximate dates
Event types and importance levels
Primary and secondary sources
Related links
Event-specific media
Bilingual captions and alt text
Attribution and licensing

This makes the content reusable, but it also introduces editorial problems that code can’t solve. What do you do when two reputable sources disagree on a date? How do you mark a timeline as incomplete without undermining it? How do you represent a source that is credible but secondary?

I’m also unsure about the public format. Custom JSON is easy to design. JSON-LD or an existing event vocabulary is harder but more interoperable. If you were consuming timeline data from an API, which would you prefer?

Bilingual support starts in the data model

Arabic is not “English with different words.” It needs RTL layout, different typography, localized dates, and interface decisions that don’t always mirror the English side.

For structured content, the simplest model is explicit bilingual fields:

{
  "title_en": "The Transformer rewrites the architecture of language AI",
  "title_ar": "بنية المحولات تعيد صياغة هندسة الذكاء الاصطناعي اللغوي"
}

This is easy to query and validate when you have exactly two languages. It becomes ugly at five or ten. A normalized translation table scales better, but it adds joins, fallback logic, and publishing-state complexity that I don’t need yet.

My current rule: reconsider the model before adding a third language, not before. Premature normalization is still premature optimization.

Media became a subsystem by accident

Once timelines started using event-specific images, storing a single URL wasn’t enough. A useful media record now needs:

A stable internal ID
Processing status and responsive variants
Dimensions and file type
Bilingual alt text and captions
Original source, attribution, and licensing
A relationship to either a timeline or an individual event

Images are processed into multiple sizes and formats. Events reference the internal asset, not an external URL. This keeps accessibility metadata attached to the thing it describes, and it avoids tying published pages to the uptime of some third-party host.

The part I can’t automate: whether the alt text is actually good. Validation checks for presence. It does not check for usefulness.

Distribution creates an attribution boundary

The more portable you make content, the less control you have over how it’s used.

Return only a title and URL, and the API is barely useful. Return full articles, and you’re inviting unattributed republication. Summaries are a middle ground, but even summaries get aggregated into faceless feeds.

Right now the API asks consumers to preserve article URLs and display visible attribution. That is a social contract, not a technical one. I’ve looked at signed content, stricter terms, metered access, and API keys. Each one raises the cost of legitimate experimentation.

If you’ve designed a public content API, how did you decide how much to give away?

What I would do differently

Start with the timeline data model earlier. Treating timelines as articles first meant a migration I could have avoided.
Question the embed strategy harder. A script tag feels like the easy path until you’re debugging CSS specificity on a site you don’t control.
Document the API’s philosophy, not just its endpoints. Developers need to know why it’s small before they decide whether to build on it.

Questions I’m stuck on

If you were reviewing this system, I’d value your take on:

Scope creep: At what point does a small REST API need categories, tags, or search?
Push vs. pull: Would webhooks for new stories be useful, or does RSS already solve that?
Embed interfaces: Is a data-* script still a good integration format in 2026?
Web Components: Do they actually solve the widget isolation problem, or just shift it?
Timeline formats: How would you represent sourced historical events in a public API?
Multilingual models: What is the least complicated model that still supports future expansion?
Content boundaries: How much article content should a public news API return?
Versioning: Which caching or contract mistakes should I fix before the API grows?

You can poke at the current implementation through the developer page, the widget builder, and the live timeline collection.

If one part of this system deserves to be simplified, replaced, or avoided entirely, which one is it?

2000 public APIs for your Next Project

Samy — Tue, 03 Jan 2023 06:49:44 +0000

Consuming API is a crucial part of learning any programming language. There is a need to integrate different systems almost in any programming project.

Mobile Apps, Websites, CRM, ... and the list is long, all require integration with other 3rd party or even internal APIs.

Practicing such will require an API to work with, and in this post, I'm shedding light on my recent work, the Public API Directory.

In this directory (APIsList) , I've compiled more than 2000 public APIs from the community and also by the direct share of the API owners, to make it easier for any one looking for his next project idea, or even integrating with an existing system.

The directory list some decisive information about each API with powerful search engine to make it easier for you to choose the correct API for your need. It does also come with pre-defiend lists such as Open Source APis list, Free APIs and APIs with CORS support.

I hope you will enjoy it, and please drop any suggestion or critisism to make it better in the comments below.

The IBAN API

Samy — Sun, 22 Aug 2021 09:52:42 +0000

I wanted to share my latest product with the community, which is the IBAN validation API.

This product offers a way of validating the IBAN and getting the bank metadata from it, such as Bank Name, Branch, address and BIC, ...

The product is growing daily by the usage of its customer whereas of today it covers more than 100 countries around the world.

I would like to share the product with the community where it will benefit you if you are in the Fintech, e-commerce, accounting, or any related sector and you require your customer IBAN where this API will boost and enhance your user experience and your system acceptance rate.

The IBAN API can be accessed through this URL.

Please let me know your thoughts and suggestions.

I've created the online tools platform

Samy — Sun, 13 Dec 2020 07:49:34 +0000

So, as many other developers, I've many tools to be used daily, such as JSON Viewer or hashing strings :)

My list of daily used tools is growing with some limitation on some tools online, as a result, I've decided to build my own tool and share it with the community.

After a few days of work, I've launched the initial version of devtools360.com intending to provide more than 100 useful tools for different use cases.

Since then I'm adding tools every week, for instance, the most recent tool was the OCR Tools, Mac address Lookup tool, and website DNS checker tool.

I thought it would be better to get dev. community feedback on what has been done, and what should be done next to make this platform more convenient and easier to use.

So please let me know your thoughts :)