Searching txt.sour.is

Twts matching #HTML
Sort by: Newest, Oldest, Most Relevant

**RT by @mind_booster: Portugal vai a tribunal. Esforços para adotar diretiva europeia “foram insatisfatórios e insuficientes”
(Avaliação do impacto ambiental)

https://www.dn.pt/internacional/portugal-vai-a-tribunal-esforcos-para-adotar-diretiva-europeia-foram-insatisfatorios-e-insuficientes-15726923.html**
Portugal vai a tribunal. Esforços para adotar diretiva europeia “foram insatisfatórios e insuficientes”

(Avaliação do impacto ambiental)

[dn.pt/internacional/portugal…](https://www.dn.pt/internacional/port … ⌘ Read more

⤋ Read More

H3: Instead of C3
[Updated with correct Gemlog link.]

A version of this was posted on on 2023-01-06 but I thought it might
also fit here. Go to my gemlog for somewhat more personal takes and
see what I publish first. IPv6 only!

gemini://gem.hack.org/mc/log/

As long-time readers know I have participated in the Chaos
Communication Congress (C3) in Germany every year since 2008.

Since C3 was cancelled this year I thought I’d arrange a very small
conference of my own. I would at least try to gather some friends and
acquaintances … ⌘ Read more

⤋ Read More

H3: Instead of C3
A version of this was posted on on 2023-01-06 but I thought it might
also fit here. Go to my gemlog for somewhat more personal takes and
see what I publish first. IPv6 only!

gemini://gem.hack.org/log/

As long-time readers know I have participated in the Chaos
Communication Congress (C3) in Germany every year since 2008.

Since C3 was cancelled this year I thought I’d arrange a very small
conference of my own. I would at least try to gather some friends and
acquaintances in chat and video conference and watch t … ⌘ Read more

⤋ Read More
↳ In-reply-to » Trying to wrap my head around webfinger..

@xuu@txt.sour.is that doesn’t seem to fit the spirit of the spec, at least by my read (I could be wrong obv). The example on Wikipedia’s webfinger page,

{
	"subject": "acct:bob@example.com",
	"aliases": [
		"https://www.example.com/~bob/"
	],
	"properties": {
		"http://example.com/ns/role": "employee"
	},
	"links": [{
			"rel": "http://webfinger.example/rel/profile-page",
			"href": "https://www.example.com/~bob/"
		},
		{
			"rel": "http://webfinger.example/rel/businesscard",
			"href": "https://www.example.com/~bob/bob.vcf"
		}
	]
}

and then the comparison with how mastodon uses webfinger,

{
    "subject": "acct:Mastodon@mastodon.social",
    "aliases": [
        "https://mastodon.social/@Mastodon",
        "https://mastodon.social/users/Mastodon"
    ],
    "links": [
        {
            "rel": "http://webfinger.net/rel/profile-page",
            "type": "text/html",
            "href": "https://mastodon.social/@Mastodon"
        },
        {
            "rel": "self",
            "type": "application/activity+json",
            "href": "https://mastodon.social/users/Mastodon"
        },
        {
            "rel": "http://ostatus.org/schema/1.0/subscribe",
            "template": "https://mastodon.social/authorize_interaction?uri={uri}"
        }
    ]
}

suggests to me you want to leave the subject/acct bit as is (don’t add prefixes) and put extra information you care to include in the links section, where you’re free to define the rel URIs however you see fit. The notion here is that webfinger is offering a mapping from an account name to additional information about that account, so if anything you’d use a "subject": "acct:SALTY ACCOUNT_REPRESENTATION" line in the JSON to achieve what you’re saying if you don’t want to do that via links.

⤋ Read More
↳ In-reply-to » Trying to wrap my head around webfinger..

@prologic@twtxt.net That was exactly my thought at first too. but what do we put as the rel for salty account? since it is decentralized we dont have a set URL for machines to key off. so for example take the standard response from okta:

# http GET https://example.okta.com/.well-known/webfinger  resource==acct:bob
{
    "links": [
        {
            "href": "https://example.okta.com/sso/idps/OKTA?login_hint=bob#",
            "properties": {
                "okta:idp:type": "OKTA"
            },
            "rel": "http://openid.net/specs/connect/1.0/issuer",
            "titles": {
                "und": "example"
            }
        }
    ],
    "subject": "acct:bob"
}

It gives one link that follows the OpenID login. So the details are specific to the subject acct:bob.

Mastodons response:

{
  "subject": "acct:xuu@chaos.social",
  "aliases": [
    "https://chaos.social/@xuu",
    "https://chaos.social/users/xuu"
  ],
  "links": [
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://chaos.social/@xuu"
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://chaos.social/users/xuu"
    },
    {
      "rel": "http://ostatus.org/schema/1.0/subscribe"
    }
  ]
}

it supplies a profile page and a self which are both specific to that account.

⤋ Read More
↳ In-reply-to » Trying to wrap my head around webfinger..

@prologic@twtxt.net That was exactly my thought at first too. but what do we put as the rel for salty account? since it is decentralized we dont have a set URL for machines to key off. so for example take the standard response from okta:

# http GET https://example.okta.com/.well-known/webfinger  resource==acct:bob
{
    "links": [
        {
            "href": "https://example.okta.com/sso/idps/OKTA?login_hint=bob#",
            "properties": {
                "okta:idp:type": "OKTA"
            },
            "rel": "http://openid.net/specs/connect/1.0/issuer",
            "titles": {
                "und": "example"
            }
        }
    ],
    "subject": "acct:bob"
}

It gives one link that follows the OpenID login. So the details are specific to the subject acct:bob.

Mastodons response:

{
  "subject": "acct:xuu@chaos.social",
  "aliases": [
    "https://chaos.social/@xuu",
    "https://chaos.social/users/xuu"
  ],
  "links": [
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://chaos.social/@xuu"
    },
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://chaos.social/users/xuu"
    },
    {
      "rel": "http://ostatus.org/schema/1.0/subscribe"
    }
  ]
}

it supplies a profile page and a self which are both specific to that account.

⤋ Read More

**Have you decided how will you be celebrating this year’s Winter Solstice yet?

@tidalclub is organizing a 24 hours long online festival, and I’ll be playing there! More info:

https://merankorii.blogspot.com/2022/12/live-at-club-tidals-night-stream.html**
Have you decided how will you be celebrating this year’s Winter Solstice yet?

@tidalclub is organizing a 24 hours long online festival, and I’ll be playing there! More info:

[merankorii.blogspot.com/2022…](https … ⌘ Read more

⤋ Read More

Ignite Realtime Blog: HTTP File Upload plugin 1.2.0 released
We have now released version 1.2.0 of the HTTP File Upload plugin!

This plugin adds functionality to Openfire that allows clients to share files, as defined in the XEP-0363 ‘HTTP File Upload’ specification.

This release primarily enhances functionality when running in an Openfire cluster. All changes can be reviewed in [the changelog for this release](https://www.igniterealtime. … ⌘ Read more

⤋ Read More
↳ In-reply-to » Atom vs. RSS: https://mckinley.cc/blog/20221109.html

@mckinley@twtxt.net Thank you! I didn’t even know about signing and encrypting XML documents. Right, RSS is a little bit messy.

Unfortunately, the autodiscovery document in one of your linked resources does not exist anymore. What annoys me in Atom is the distinction between <id> and <link>. I always want my URL also to be my ID, so I have to duplicate that – unnecessarily in my opinion.

Also, never found a good explanation why I should add <link rel="self" … /> to my feeds. I just do, but I don’t understand why. The W3C Feed Validation Service says:

[…] This value is important in a number of subscription scenarios where often times the feed aggregator only has access to the content of the feed and not the location from which the feed was fetched.

This just sounds like a very questionable bandaid to bad software architecture. Why would the feed parser need access to the feed URL at this stage? And if so, why not just pass down the input source? Just doesn’t make sense to me.

Also, I just noticed that I reference the http://purl.org/rss/1.0/modules/syndication/ namespace, but don’t use it in most of my feeds. Gotta fix that. Must have copied that from my yfav feed without paying attention what I’m doing.

Your article made me reread the Atom spec and I found out, that I can omit the <author> in the <entry> when I specify a global <author> at <feed> level. Awesome! Will do that as well and thus reduce the feed size.

⤋ Read More

Ignite Realtime Blog: Openfire 4.7.4 release
The Ignite Realtime Community is happy to announce the 4.7.4 release of Openfire. This release fixes a number of bugs and represents our effort to provide a stable 4.7.x series while work continues on the next feature release of Openfire.

Notable fixes include enhancements to cluster-specific implementation of Multi-User Chat functionality, improved websocket handling and improv … ⌘ Read more

⤋ Read More

ProcessOne: ejabberd 22.10
This ejabberd 22.10 release includes six months of work, over 140 commits, including relevant improvements in MIX, MUC, SQL, and installers, and bug fixes as usual.

Image

This version brings support for latest MIX protocol version, and significantly improves detection and recovery of SQL connection issues.

There are no breaking changes in SQL schem … ⌘ Read more

⤋ Read More

ProcessOne: ejabberd 22.10
This ejabberd 22.10 release includes five months of work, over 120 commits, including relevant improvements in MIX, MUC, SQL, and installers, and bug fixes as usual.

Image

This version bring support for latest MIX protocol version, and significantly improves detection and recovery of SQL connection issues.

There are no breaking changes in SQL schem … ⌘ Read more

⤋ Read More