My upgrade script get stuck on this Build finished at 13:19:30 by 0.000s Build finished at 13:19:30 by 0.000s Build finished at 13:19:30 by 0.000s Instead of the normal one: Build finished at 13:19:30 by 0.000s Build finished at 13:19:30 by 0.000s Build finished at 13:19:30 by 0.000s 2025-01-05T13:19:31.074Z [4567,4568/2226960] - info: [build] Bundling took 7664 ms 2025-01-05T13:19:31.076Z [4567,4568/2226960] - info: The only issue is that my script manager does not get the signal of "done" and then I ineed to reset the deployment status. Not a big deal, but I would love to know if this is common and what can I do to force the end of the gbuild. Thanks

@julian Happy new year! I was out for the holidays. I will double check other files. I saw a lot of those but it could be all on the same files. On a quick look I found also https://app.transifex.com/nodebb/nodebb/translate/#es/$/453829424 and https://app.transifex.com/nodebb/nodebb/translate/#es/$/453829416 and many others which are part of global, so I would guess this is everywhere and the Spanish translation % is not real. Maybe it would be easier to start fresh with a clean translation? Thanks!

silverpill1:I'm using the term "origin" as defined in RFC-6454. This is also what FEP-fe34 refers to.Thanks for the clarification. silverpill1:FEP-fe34 doesn't require embedded object to have same origin as the containing object (but it says that embedded object with a different origin shouldn't be trusted).I was referring to the Athentication section that states four conditions (none of which are satisfied for an embedded actor key from a different web origin) and says:If none of these conditions are met, the object MUST be discarded.If the embedded "object" is the key in the actor fetch scenario, discarding it wouldn't be desirable. If you intended to suggest that the key/object should be dereferenced for verification, the wording should be changed. silverpill1:FEP-fe34 doesn't mention actor/key relationship because location of an actor document is not important for authentication via HTTP signatures. Only location of a key is important.After rereading the FEP Authentication several times, I think( I see what you are trying to specify. You want the HTTP Signature key web origin to be the same as a POSTed activity URI web origin (but it could be different than the actor URI web origin?). However, I don't know why you believe that specific key/activity web origin restriction is necessary. silverpill1:As far as I know, all existing implementations behave in this way and don't put public key on a different server than actor.To the extent the FEP is documenting existing practices (although using requirements language), that's fine. Developers should be aware that the way Mastodon-like servers have implemented AP+Signatures is not the only valid way to do it. Like I said before, even Mastodon doesn't appear to have the restrictions that you are proposing (for incoming posted activities). silverpill1:If some document contradicts both FEP-fe34 and implementer consensus, it is probably not correct and should be fixed. I can look into it if you point to a specific paragraph or sentence.I'm not sure it contradicts the SocialCG's HTTP Signature, but it adds unnecessary and undesirable restrictions to it. You can also take a look at Mastodon's handling of HTTP Signature key verification to explore how the FEP differs from current practice. It might also be useful to have a section discussing the similarities and differences with current popular server implementations.Also, about web origin... the AP specification uses the term "origin" in a very ambiguous way. It doesn't reference web origin (RFC-6454) at all. Some references to "origin" appear to mean the "actor who originated an activity". For example,The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.This could be interpreted as the Update should originate from the same actor as the object being modified, which is reasonable. That interpretation doesn't require the actor and the object URIs to have the same RFC-6454 web origin.Again, it's very ambiguous so it's possible to have different interpretations. However, I don't agree with some parts of the FEP-fe34 interpretation.

@phenomlab found the plugin, thanks!

Had posted in the Github of an issue way back in March but, nothing has been done with it since.

ERROR in ./build/public/src/modules/topicThumbs.js 104:6-106:8 Module not found: Error: Can't resolve 'composer' in '/home/xxxxx/htdocs/xxxxx/build/public/src/modules' Activate nodebb-plugin-composer-default and then rebuild restart again.

@[email protected] do you mind cancelling the meeting for today?

having the same problem, any luck?

@VE2UWY @Vivaldi DDG is a good choice, but if you want Google results, you might be able to use Startpage or Ecosia as well.

@julian Peertube account follows are now working, but I did not get any video from @[email protected] in my feed yet. Ready to wait a few more days for that. However, (meta) Threads accounts seems to be unfollowable even now.

@baris Is there any other open-source server which can be used for geocoding with this plugin instead of mapbox api?

@baris said in MacOS ./nodebb setup fail: Try nodejs 18/20 or 22.

@julian Hi, yes for sure. "Source" or "Location" are pretty common data points that add more granularity in organization/sorting/searching. An example of a non text field would be something like "beginning date" and "end date" that would need to be date or number. I'm admittedly new to nodebb, but I it would seem copy/pasting whatever was done to the users codebase and replacing the variables names would be perfect for both categories and topics.

As the title says. I don't have money to buy a server.

@julian @jenniferplusplus @silverpill for example, if you intend to have a Move activity show up in the displayed conversation, it would in theory have two contexts: one context binds the activity log, and the other context binds the current conversation itemsif both are declared explicitly, then the way you’d tell the two apart is by some heuristic (probably using new types or properties). but the activity log context may be implicit by way of the outbox.

@bboctt Nice nice nice. Okay, here are my thoughts on it... there are some applications for print view even in 2024/2025. One of those is reader mode. For whatever reason, NodeBB doesn't format well at all when sites try to remove extraneous elements and keep just the post text. if you don't care so much about getting the entire topic history, you could just get the existing topic data on-page by querying ajaxify.data. You can retrieve additional pages by passing ?page= param.

Just a shuttlecraft based toy activitypub server running on github workspace

@bboctt oh lord!! The ever-lasting battle between compatibility and adoption of new features. At the end of the day, supporting older browsers gives us enough developer friction as to become a no-go. That's not to mean that it isn't important, but unfortunately that the market share isn't there for us to spend a significant amount of time on it. But let's say... if a big bank came to us and said "This forum needs to work on IE11!!", and was going to spend the dollars to get the software there, then that is a different story. On the upside, though, there are a couple small things we can try to address. The site's client-side js shouldn't immediately crash... stuff should work. It may be worth investing some time into getting the baseline functionality working, if it isn't already.

nothing happens on click