Notices by Yukkuri (iamtakingiteasy@eientei.org), page 6

Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 09-Feb-2024 02:48:09 JST Yukkuri
in reply to
- Lina Inver:z:e :mur_close: :nuts:
@lina Не пользуюсь home-timeline'ом, но похоже нет.

In conversation about 10 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Wednesday, 31-Jan-2024 03:18:03 JST Yukkuri
- prettygood
@prettygood
In conversation about 10 months ago from eientei.org permalink
Attachments
1. Untitled attachment
Yukkuri (iamtakingiteasy@eientei.org)'s status on Sunday, 28-Jan-2024 22:55:16 JST Yukkuri
in reply to
@mint @theorytoe @locagainstwall @lina stat.ripe.net has that (and generally a bunch of convenient tools in one place, including BGP updates), but it too doesn't have any whois data prior to 2023-07-09 here.

In conversation about 10 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Sunday, 28-Jan-2024 20:17:30 JST Yukkuri
in reply to
- Lina Inver:z:e :mur_close: :nuts:
@lina @mint Eientei defederates no instances and it is not clear which specific account you refer to as "him", but most likely no.

In conversation about 10 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Sunday, 28-Jan-2024 20:17:28 JST Yukkuri
in reply to
- Lina Inver:z:e :mur_close: :nuts:
@lina @mint Neither of these is limited in any manner.
In conversation about 10 months ago from eientei.org permalink
Attachments
1. Untitled attachment
  https://eientei.org/media/7e78eb3b73480454485b1e705dd038d2ae539f5868c816f5a80ce3c53c597ce3.png?name=image.png
Yukkuri (iamtakingiteasy@eientei.org)'s status on Sunday, 28-Jan-2024 00:14:42 JST Yukkuri
in reply to
@Griffith @NathanielHigger1488 @TornadoOfTerror
In conversation about 10 months ago from eientei.org permalink
Attachments
1. Untitled attachment
  https://eientei.org/media/383d577591d6cfd33df3302c9921e0e6f9db326067d0b0e52a50cdd1b091b99a.png?name=image.png
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 26-Jan-2024 22:12:20 JST Yukkuri
in reply to
@DarkMahesvara @lina @mint @Azur_Fenix @Moto_Chagatai

> few post before it was days after.
I'm talking about this portions [picrelated].

> either way why would you assume someone who hacked someone would say the truth about that person.
It is generally more effective to expose an actual dirty secret than fabricate one and risk being caught, loosing entire retrospective credibility. Since credibility attribution is rather strong here (not exactly anonymous), we can at least take into account the levels of bluff required when making a judgement.
In conversation about 10 months ago from eientei.org permalink
Attachments
1. Untitled attachment
  https://eientei.org/media/02a8ee0961b83ed7a5aeb87b75de45c7c03f85450e59624352728007352a4c2f.png?name=image.png
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 26-Jan-2024 21:53:34 JST Yukkuri
in reply to
@DarkMahesvara @lina @mint @Azur_Fenix @Moto_Chagatai Such instances are usually displayed in iknowwhatyoudownload as matching first and last seen date, which isn't the case here, so there is a stronger evidence of hash attribution to the ip, unless exact same ip was reused by pollution bots within an hour.

In conversation about 10 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Wednesday, 17-Jan-2024 22:39:56 JST Yukkuri
in reply to
@menherahair @Zerglingman @MK2boogaloo @Suiseiseki @anonymous
In conversation about 10 months ago from eientei.org permalink
Attachments
1. Untitled attachment
  https://eientei.org/media/79be1edac86eb56a66c9190463fcfa8b99d63063554551b368d056980a4adac5.png?name=ba7d8c2b46ad054e4cea34ee90561b59.png
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 12-Jan-2024 03:35:45 JST Yukkuri
@p @Terry @colonelj @sjw @colonelj @lanodan @mint @Moon 202 is more of "okay then, now go away". It's exactly as what happens in pleroma - we'll enqueue it for incoming federation, but there is no guarantee of causing any intended side-effects (may be dropped silently by MRF for example) and since entity is identical, no storage changes are expected.

409 per same spec is more of "hey, you tried to take the nickname that is already in use, fix that and retry right after". In case of APID conflict in server-to-server communication, there is nothing really server can change, and per RFC:

> This code is only allowed in situations where
> it is expected that the user might be able to resolve the conflict
> and resubmit the request

In conversation about 11 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 12-Jan-2024 03:20:19 JST Yukkuri
@p @Terry @colonelj @sjw @colonelj @alex @lanodan @mint @Moon It can also be debated whether 409 error is applicable in case of identical entity being re-posted, since there is nothing short of submitting wholly different entity that would avoid the error reoccurrence in this case. 202 sounds more fitting.

In conversation about 11 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 12-Jan-2024 02:34:27 JST Yukkuri
@Moon @Terry @colonelj @sjw @feld @colonelj @lanodan @mint @p If you want to be compliant with jsonld, even if you don't use it, you must support field prefixes, so you must also parse jsonld specs themselves to know which ones you may ignore. If you want to be a dick, you are technically allowed by the spec to federate something like
{ "@context": { "fuckyou": "https://www.w3.org/ns/activitystreams", "@vocab": "https://fuck.you" }, "fuckyou:type": "Note", "fuckyou:to": ["https://www.w3.org/ns/activitystreams#Public"], "fuckyou:content": "Fuck your efficient json parsers." }
In conversation about 11 months ago from eientei.org permalink
Attachments
1. No result found on File_thumbnail lookup.
  
  ActivityStreams 2.0 Terms
  
  This document lists the terms used for the ActivityStreams 2.0 protocol and its stable extensions, and provides a namespace so each term has an HTTP IRI.
2. No result found on File_thumbnail lookup.
  
  ActivityStreams 2.0 Terms
  
  This document lists the terms used for the ActivityStreams 2.0 protocol and its stable extensions, and provides a namespace so each term has an HTTP IRI.
3. Untitled attachment
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 12-Jan-2024 02:06:24 JST Yukkuri
@Moon @Terry @colonelj @sjw @feld @colonelj @lanodan @mint @p I think pleroma is on the right ignoring all JSONLD crap and just treating it as extra fields without particular meaning.

In conversation about 11 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 12-Jan-2024 01:56:20 JST Yukkuri
in reply to
@feld @Terry @colonelj @sjw @colonelj @lanodan @mint @Moon @p Yep, that is a reasonable way to implement it, user-specific inbox only adding one implicit `to` for server logic.

Also whole AP spec type dynamism makes it rather unpleasant to work with, every field may technically be an IRI, an object, a list of IRIs, a list of objects, or not be there at all, then there are JSONLD shenanigans with extra fields and field schema prefixes on top of that. A fully *compliant* implementation would be woefully inefficient, having to deal with all that extra bulk.

In conversation about 11 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 12-Jan-2024 01:44:28 JST Yukkuri
in reply to
@mint @Terry @colonelj @sjw @feld @colonelj @lanodan @Moon @p Sounds like an inconsistent implementation, rather than what spec described.

In conversation about 11 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Friday, 12-Jan-2024 01:24:09 JST Yukkuri
in reply to
@mint @Terry @colonelj @sjw @feld @colonelj @lanodan @Moon @p Lists of recipients are all optional, I suppose those were an afterthought, when they realized pushing separate rest endpoint for every recipient isn't viable.

In conversation about 11 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Tuesday, 09-Jan-2024 20:48:53 JST Yukkuri
- menherahair
- ロミンちゃん
@romin @menherahair killing user terminal multiplexer sessions on disconnect no longer optional. Billions must -9
In conversation about 11 months ago from eientei.org permalink
Attachments
1. Untitled attachment
  https://eientei.org/media/16bd5c43ebefd44bc1d7b4620862ac00aa18da0cffcf01766177db1cbc409273.jpg?name=cirno_3.jpg
Yukkuri (iamtakingiteasy@eientei.org)'s status on Saturday, 06-Jan-2024 22:17:28 JST Yukkuri
in reply to
- kaia
- menherahair
@menherahair @kaia It isn't so much question of good or bad, ceramic/ceramogranite is always hard and therefore brittle. Tiles have near no elasticity, hence only way for kinetic energy to dissipate is to introduce a fracture. ~5kg dropped from 1.5-2 meters with spherical point of contact may crack or chip away virtually any tile with standard for 60x60cm ~1cm thickness if underlying surface is also hard and rigid. Spares certainly do help, but if you ever replaced an isolated tile, you'd know the fun of clearing out remains of old tile and then trying to level/align fresh adhesive with already set from adjacent ones. Laminated wooden tiles are much more serviceable, and come in heavy duty certified variants too.

> please wear something + you are from Russia
I'll leave that to burger golems.
In conversation about 11 months ago from eientei.org permalink
Attachments
1. Untitled attachment
  https://eientei.org/media/826581d70302180725a7b42f22ba8c2fff0508060768469ef4403ce08106de89.jpg?name=ezc3tik1pyw91.jpg
Yukkuri (iamtakingiteasy@eientei.org)'s status on Saturday, 06-Jan-2024 22:10:02 JST Yukkuri
in reply to
- kaia
- menherahair
@menherahair @kaia Until you drop something heavy on one and it cracks, then you have to hope matching ones are still produced and color don't vary between series too much. Also other than for office buildings, a floor heating system may be required, otherwise tiles can get really cold to be used without footwear; and those are real pain to maintain and repair.

In conversation about 11 months ago from eientei.org permalink
Yukkuri (iamtakingiteasy@eientei.org)'s status on Saturday, 06-Jan-2024 04:17:38 JST Yukkuri
in reply to
@sjw @Terry @colonelj @p @mint Most likely entry isn't removed from oban federator_outgoing queue. Purely software errors might get recorded in errors column, that should be easiest to check first, if not, enabling debug logs, triggering/waiting for delivery attempt and then sifting through many megabytes of output would be required. Postgres logs at the same moment might also be helpful. Could be conflicting lock, transaction getting rolled back due to software error or some database error. Either way, combined output is likely to contain some hints.

Further speculations include runtime cache(s) not getting evicted, lingering oban workers from restarts/reloads without terminating main process. If issue stops reproducing after clean instance restart, could be the case, but locating such issues is ought to be involved and interactive process.

Could also be synchronization issue, if multiple workers somehow are getting the same task, but thats nearing improbability, it's not that difficult to implement row-locking postgres queue correctly to doubt oban implementation before other options are exhausted.

In conversation about 11 months ago from eientei.org permalink

After
Before

Public

Notices by Yukkuri (iamtakingiteasy@eientei.org), page 6

User actions

Following 0

Followers 0

Groups 0

Statistics

Feeds