Opting Out

Has there been any thought given to how a room admins or homeserver admins could opt out their room or server?
My thought would be some sort of state event in a room and the already standard X-Robots-Tag for servers.
I know this project is in very early stages but given the distributed nature of the matrix network I believe this to be a very important thing, especially coming from the matrix core team (Or at least that's who it looks like it's being driven by).

Related MSC's:

MSC2291
MSC4021

The archive will only access rooms where the history is world_readable. A room can be public without world_readable history so there is already mechanism to sorta control this.
But it is possible that we add an additional signal/control to determine whether search engines should index it. I imagine that you would still be able to access the room via Matrix public archive but we would tell Google not to index the room if that signal is present.

Will removing world readability effect the archive or will the past history still be visible using it?
Is there any mechanism in Matrix for redacting the past public history that any room administrator can use without resorting to running bots/servers or unspecced hacks (m.room.retention and specced changing history visibility to members only and /upgraderoom 10)

Another concern is do tombstoned rooms automatically get excluded by both this and matrix-static? They may be inaccessible if they have weird join rules and no one to invite.

Will removing world readability effect the archive or will the past history still be visible using it?

@Mikaela I'm not sure exactly how the m.room.history_visibility lookup will happen exactly (current state or state at the time). It depends on that.

Is there any mechanism in Matrix for redacting the past public history [...]

Best to create an issue and ask elsewhere about this.

Another concern is do tombstoned rooms automatically get excluded by both this and matrix-static? They may be inaccessible if they have weird join rules and no one to invite.

Any world readable rooms, including tombstoned. I don't have any details about the other project, matrix-static.

Related to https://github.com/matrix-org/synapse/issues/14127

I have a few rooms that are set to world_readable and published to my homeserver's room directory that I don't want to be on my public archive site. My solution was to simply ban the archive bot from those rooms. This really isn't a good solution because the rooms are still listed and when you try to view them you get an error page.
What if the archive backend was to query all the rooms to check if its bot has access? If it is banned from a room then it would remove that room from the list on the website. It could also re-check when a user tries to view that room.

@Cyberes The app is stateless so we can't just hold onto that kind of access/ban information across requests. It needs to be something we can query from the API and for the room directory, we wouldn't want to make a separate look-up for every single room we're trying to display in the grid so it needs to come from the room directory, /publicRooms endpoint.
A new state event that like X-Robots-Tag/<meta name="robots" content="noindex, nofollow"> that the issue description mentions seems like a good way to go. The room directory can relay this information just like it already does for join_rule and world_readable. A new MSC needs to be created for this though.

If you can share the details, what's the distinction that your rooms should be public, world_readable but not accessible in the archive? Trying to understand the context/use-case.

The rooms that fit the public world_readable but excluded from the archive are all related to "server administration" such as announcements, the room for things relating to the homeserver, etc. It's fine if a user from another HS finds and joins those rooms but I'd rather not have them public on the internet (you know what they say, "the internet never forgets" or whatever).

Really not sure about how fit for purpose using public world_readable is as a basis for inclusion in the archive. I'm going to assume that world_readable equates to Anyone in the Room Security & Privacy options in Element. So, if you want people to see content before joining the room it will get archived.
Changing the setting to Members only (since the point in time of selecting this option), but doesn't change the visibility of existing history. And, if @archive:matrix.org is still a member of the room?
At least for now, banning the bot seems like the only solution, but the resulting 403 is really doesn't look good for the archive.

So apparently when room is publicly joinable and only showing history for members, it may show history on archive.matrix.org for the first one who tries to access it, until a Draupnir/Mjolnir triggers and bans the bot which will stop subsequent visits to the page?

https://matrix.to/#/%23furrytech%3Amatrix.org/%24IifH_2lqoP2raQ7wUSMZWBIWFvSRrSuHkyEKj9HONpM?via=777.tf&via=matrix.org&via=tedomum.net

After the bot joined a room with history visibility set to joined, it rightfully showed an error on the website. However, the error says

StatusError: 403 - Only world_readable or shared rooms that are public can be viewed in the archive.

shared rooms should not be archived, only world_readable rooms should be.

shared rooms should not be archived, only world_readable rooms should be.

"archived" is a bit of a overloaded term here but given that this project is called "Matrix Public Archive" I can see where the confusion may be be coming from. Any public room should be viewable in Matrix Public Archive. The idea is if a random Matrix user can view the room, then it should be viewable in the archive. But only history_visibility: "world_readable" rooms are indexable by search engines.
The Matrix Public Archive doesn't hold onto any data (it's stateless) and requests the messages from the homeserver every time (it archives nothing). The archive.matrix.org instance has some caching in place, 5
minutes for the current day, and 2 days for past content.
I've tried to clarify more of this in the FAQ document and added more details on why not guest access/peeking.
Banning @archive:matrix.org will prevent the room from showing up on archive.matrix.org and the cache will expire after 5-minutes/2-days for any content that is showing there now. Adding better opt-out controls like this issue is discussing is on the list :+1:. I've updated the description with the current MSC proposals out there.

Related: #257

@MTRNord Could you please read the past messages? Or at least mine https://github.com/matrix-org/matrix-public-archive/issues/47#issuecomment-1570861030

@MTRNord Could you please read the past messages? Or at least mine https://github.com/matrix-org/matrix-public-archive/issues/47#issuecomment-1570861030

I don't see how your message is in any way relevant to my question? It displays contents and Google can crawl it. Clearly my questions apply. No matter the name of it. It's not the point I was making.

Additionally @bkil going by the statement of you and the prior explanation of how this works by @MadLittleMods shouldnt the whole thing be opt in based on admin decission rather than opt out? (that's basically the tldr of my first part of my initial question)

@MTRNord It is already opt-in. You opt-in by making your room world-readable.

The default room creation dialog recommends private access. If you deliberately make it public, you are signalling consent.
If you select the public join rule here, the created room will by default with the history access set to Members only (since the point in time of selecting this option). You still need a specific admin action to enter the room settings and change this to world readable, that could actually be considered a second opt-in action.
As per my comment, this is effectively meant to be considered a nojs matrix client, hardly a third party service. Could we take this talk to a specific matrix room perhaps if you have any further question?

Furthermore, although only a few web scrapers support running limited JavaScript for a few seconds as of now, what kept either a deep pocket existing player or a new startup in the future from running scripts for much longer duration of time and with greater compatibility?
It would not be that much of a barrier for them to then bump into matrix.to links that could lead them to opening matrix rooms via web clients either after automatically joining with a guest account or by using the established room preview button.

/me considers this discussion a lost hope and acl Bans matrix org instead. Thanks.

I consider this discussion a lost hope and decide to not further engage with bkill and wait on other opinions instead :)

But also, it was not obvious to many of us that this project aims for 5 minutes/2 days ephemeral caching.

I'd be curious where do you take that from; I discovered that issue from the blog article explaining the feature-parity with Gitter. Whether it is that article or the README from this repo, it is pretty clear it want to reproduce Gitter's operation, which was a complete indexing of the content.
If that would be the case, it changes a lot of things on how people interact and use such a tool when you know that everything you say will be hard written and searchable by anyone for the years to come, which would require to at the very least clearly inform people (slightly out of topic, but in the same time on-topic: this is the same kind of issues when Matrix offer server-side logs for irc channels where users wouldn't expect this to exist). For my part this is the exact reason for which I never used Gitter. I don't intend for a chat to log and make it available to search engines everything I say.
I'm following the issue for some time now (since the blog article), but didn't knew where to raise the question: I clearly agree with @MTRNord this would need to be an opt-in rather than opt-out, and duly inform people about this.
As for your latest remark @bkil: Technically nothing prevent that. Ethically and legally on the other hand, yes.

@Porkepix

But also, it was not obvious to many of us that this project aims for 5 minutes/2 days ephemeral caching.

I'd be curious where do you take that from; I discovered that issue from the blog article explaining the feature-parity with Gitter. Whether it is that article or the README from this repo, it is pretty clear it want to reproduce Gitter's operation, which was a complete indexing of the content.

It was mentioned at Matrix by @MadLittleMods

https://matrix.to/#/%23matrix-public-archive%3Amatrix.org/%24h2Z66FeNtc5B3Ps38ZVC8rvjTgojf_IWFEpAxF797-s?via=matrix.org&via=element.io&via=evulid.cc

It was also added to the FAQ

https://github.com/matrix-org/matrix-public-archive/blob/main/docs/faq.md#why-does-the-archive-user-join-rooms-instead-of-browsing-them-as-a-guest

@Porkepix

But also, it was not obvious to many of us that this project aims for 5 minutes/2 days ephemeral caching.

I'd be curious where do you take that from; I discovered that issue from the blog article explaining the feature-parity with Gitter. Whether it is that article or the README from this repo, it is pretty clear it want to reproduce Gitter's operation, which was a complete indexing of the content.

It was mentioned at Matrix by @MadLittleMods
* [matrix.to/#/%23matrix-public-archive%3Amatrix.org/%24h2Z66FeNtc5B3Ps38ZVC8rvjTgojf_IWFEpAxF797-s?via=matrix.org&via=element.io&via=evulid.cc](https://matrix.to/#/%23matrix-public-archive%3Amatrix.org/%24h2Z66FeNtc5B3Ps38ZVC8rvjTgojf_IWFEpAxF797-s?via=matrix.org&via=element.io&via=evulid.cc)

This link end up with an error and just showing the chan, explaining that

Failed to load timeline position
Tried to load a specific point in this room's timeline, but was unable to find it.

The idea is if I can view the messages from a Matrix client as a random user, I should also be able to see the messages in the archive.
Keep in mind that only rooms with history visibility set to world_readable are indexable by search engines. The Matrix Public Archive doesn't hold onto any data (it's stateless) and requests the messages from the homeserver every time. The archive.matrix.org instance has some caching in place, 5 minutes for the current day, and 2 days for past content.

This is unclear to me, but as I understand it, the archive doesn't store, but when the bot crawl, it's relaying everything to the crawler, let's say Google. Which in turns mean that while the Archive server, indeed, doesn't store anything but cache, Google is. And I think it's the point here, that this shouldn't be a default behavior and should absolutely be advertised in a very visible way to users.
Users with personal log is a thing, available logs when you join is another already exposing much more. Have those logs crawled and indexed allowing anyone to search in them globally  for who knows how much time is even another, on a much different scale with much different consequences.

Odd that you single out Google, as they are actually the good guys here. All better search engines periodically recrawl and validate their index and remove stale entries, especially ones where your server returns 3xx or 4xx. Those that also host a web cache for their search results (instead of implementing a live proxy) will also purge the respective entries in such cases.
What you should be actually worried about is archiving services finding such links, because taking those down should usually be considered impossible for one who is not the owner of the given crawled portal but just a "commenter":

https://github.com/bkil/freedom-fighters/blob/master/en/service/web-cache-archive.md#user-content-mementoweb

Odd that you single out Google

https://en.m.wikipedia.org/wiki/Google_(verb)

Odd that you single out Google, as they are actually the good guys here. All better search engines periodically recrawl and validate their index and remove stale entries, especially ones where your server returns 3xx or 4xx. Those that also host a web cache for their search results (instead of implementing a live proxy) will also purge the respective entries in such cases.

Whether you think they're good guy or not here because some of their practices here would be better misses the point: for the server to return 3xx or 4xx means the content was removed. So unless people develop tools to removed all of their messages in short time after they were written (which might well be the solution here…), they'll still be available at anytime on whatever search engine or archiving services you prefer that crawls it and offer that to anyone with a search interface.
Google was the easy name to throw here being massively the most used in most countries, but that apply to anything else.

@Mikaela I mean, I'm using quite a few web search engines in parallel and I do see some that are updated within minutes but also others that have indexes that are many years old. (Yes, kind of weakening my point here :wink: ) The big players are usually the better ones in this respect according to my stats.

Let me try to elaborate here about #47 and #239 so I don't overload the issue tracker:

https://archive.matrix.org/r/securemessagingapps:matrix.org/date/2023/06/01?at=$AEeGOiIiO_D05qnjIW0Ninx501xznY1y2LalOOsi52Q

Hm I fail to see how that's in any way on topic here. Especially since none of your accusations seem to be applicable to users in this issue or the pr. 🤔 Also as repeated earlier you still don't seem to understand the basic definition of consent. Just because you give consent to thing A doesn't mean you give it to thing B just because thing B uses the same Api. And in matrix specifically having a way to fine grain this was an afterthought. Just because I made a room punlic 4 years ago means I am agreeing to service X in 7 years. That's not possible since I can't know about sich a service. Hence such service can't have consent unless given explicitly. You can't inherit consent from a setting you choose to use. Consent works by having a dedicated "I agree with this service" button. And it's applying to all services. Not just the archive. If let's say a John Doe comes around making an archival service that allows you to print a postcard of any room with public readable on matrix doesn't mean that this service has consent from the user to do that. That thing is commonly known as "abuse" or "abusive behaviour" since you claim to have consent while not having any.

Even as it stands today, the Matrix Public Archive is respecting history visibility.

I would argue that it's not respecting shared to room members-only. It's non-consentually resharing what happens in the room to unknown parties, although those would be free to join Matrix properly (or even follow the guest access rules) to get the history shared.

Hi, I apologize if the tone sounds harsh, but I believe that the default behavior of this robot has been disruptive to one project that I participate in and that I and others are not at fault here and we have better things to do.
Most channels don't have guest access for the same reasons that only a fraction of IRC channels did; "everything is searchable on Google" can change some peoples' behavior. It's a sane opt-in default that leads to a very specific behavior, I am not sure why you'd have the bot not keep that behavior.
Not only does it essentially emulate a behavior that's disabled as a sane default at a greater and more organized scale without e.g. asking admins if they want to enable that, but it's also explicitly not clear if we can kick it out and invite it later back in if we decide that we actually do want it. The design right now is, in my honest opinion, very user-hostile and I would think that this was being done by a very malicious party if this repository was not under the matrix-org namespace.
It is obvious that no admins of the rooms you're talking about were consulted whatsoever, so you just essentially actively made that decision for them while circumventing the due procedures of a specific community. Lowering the barrier of just joining the channel (there's already a setting for that, and it doesn't have anything to do with world readability!) out of nowhere is dangerous and can amplify campaigns of targeted harassment against small-to-medium-sized communities.
Like, I get what you're trying to do with this, but this would seriously be fixed if you just sent a message to the admins or in the room explaining the situation and asked them if they wanted to opt-in or something; this is just absolutely awful.

Why is this opt-out and not opt-in, you creeps. Come on.

Hi, I previously deleted a comment which I thought that was too harsh given the context, as the concerned channel was apparently visible to guests too and that it did not concern "Members only" options.
I am reposting it with some small amends, as it apparently does not respect "Members only" options either:

Hi, I apologize if the tone sounds harsh, but I believe that the default behavior of this robot has been disruptive to one project that I participate in and that I and others are not at fault here and we have better things to do.
Most channels don't have guest access for the same reasons that only a fraction of IRC channels did; "everything is searchable on Google" can change some peoples' behavior. It's a sane opt-in default that leads to an explicitly defined behavior, I am not sure why you'd have the bot not maintain that behavior.
Not only does it essentially emulate a behavior that's disabled as a sane default at a greater and more organized scale without e.g. asking admins if they want to enable that, but it's also explicitly not clear if we can kick it out and invite it later back in if we decide that we actually do want it. The design right now is, in my honest opinion, very user-hostile and I would think that this was being done by a very malicious party if this repository was not under the matrix-org namespace.
It is obvious that no admins of the rooms you're talking about were consulted whatsoever, so you just essentially actively made that decision for them while circumventing the due procedures of a specific community. Lowering the barrier of just joining the channel (there's already a setting for that, and it doesn't have anything to do with world readability!) out of nowhere is dangerous and can amplify campaigns of targeted harassment against small-to-medium-sized communities. Any hypothetical abuse vector used as an excuse to justify the current behavior of this bot is not comparable, as it presumes esoteric knowledge on the end of a user and removes the capacity to detect brigading campaigns through suspicious join events.
Like, I get what you're trying to do with this, but this would seriously be fixed if you just sent a message to the admins or in the room explaining the situation and asked them if they wanted to opt-in or something (or actually respected the settings of a channel); this is just absolutely awful.

I want to never, ever, ever feel the need to write an entire essay to this organization for something that should be obvious to an organization developing infrastructures for communities and open-source projects.
No matter if you think that you can implement it in a way that is better / more ethical, the existence of a service joining channels out of nowhere (while letting everyone else try to put the pieces together as to why it exists, how it joined, did somebody invite it?, etc.) wastes time of volunteers using Matrix to figure out what changed in their channel and what implications it may have.
There's a clear power imbalance, you have the matrix.org infrastructure that cannot have any accountability whatsoever and are also being paid to clean the entire thing with the "move fast, break things" approach. On the other hand, you have a lot of communities that depend on you and have to figure out what's going on with their channel with zero communication whatsoever. I spent at least 2 hours of limited, volunteering time examining what was happening, and there were more people involved.
Discord uses announcements to explain changes in the way people run their communities. You can announce stuff server-wide in IRC. The UX problems that exist in Matrix are not the fault of the communities that chose your service and the "move fast, break things" approach to this is in every way super annoying, especially with the Trust & Safety implications that were dismissed with a series of whataboutisms.

Do I understand correctly that the whole XMPP protocol is also opted-in to the bot with no method of opting out?

https://archive.matrix.org/r/xmpp_xsf_muc.xmpp.org:matrix.org

I had just another thought about this:
Would it help any admins or in general if the bot instead of silently joining would announce what is happening and link to its privacy policy as well as the FAQ? Currently, it joins silently, which feels like intentionally wanting to stay under the radar, even if that's not intentional. I think at least in some cases having the bot explain itself might help with acceptance and also allows room admins to more easily and quickly opt out if they wish to do so.

Hi I'm a Libera channel op and my channels' policy is to kickban anyone with [m] in their nick. Matrix bridges with their "we remember everything forever by default" are bad enough, this is just appalling and I agree with @n0toose's comment above.

The design right now is, in my honest opinion, very user-hostile and I would think that this was being done by a very malicious party if this repository was not under the matrix-org namespace.

I'd also point to Libera's own public logging policy: https://libera.chat/policies/#public-logging

Some projects may wish to log their channels publicly, if you do so the logging should be authorised by the channel owners and users in the channel should be notified (through for instance the topic, entry message, or similar) that public logging is taking place. Channel operators should consider ways for users to make unlogged comments and a process for requesting the removal of certain logs.
If you operate a service that scrapes internal channel content or published logs, ensure that you have obtained permission to do so from Libera Chat staff or the channel owners before you start scraping data, also make sure that there is an easy way for channels to opt-out.
If you wish to publish logs of a single conversation, please make sure you have gotten permission from all participants before doing so.

Hi I'm a Libera channel op and my channels' policy is to kickban anyone with [m] in their nick. Matrix bridges with their "we remember everything forever by default" are bad enough, [...]

And what do you want in a matrix related Issue?
It looks like you are hostile against Matrix. Kickban anyone with [m] in their nick is your choice, but it's wierd that you are commenting matrix project which you seems to hate...

Hi I'm a Libera channel op and my channels' policy is to kickban anyone with [m] in their nick. Matrix bridges with their "we remember everything forever by default" are bad enough, [...]

And what do you want in a matrix related Issue? It looks like you are hostile against Matrix. Kickban anyone with [m] in their nick is your choice, but it's wierd that you are commenting matrix project which you seems to hate...

Whether they hate it or not is a thing, and I won't comment on this. But it's completely legitimate even for non-users to comment on such matters considering due to the various bridging here and there even non-users are affected by things such as public logs available to everyone, or public indexing/crawl/scrapping resulting in logs that can be searched for in search engines.
Ie. a pure IRC user with many matrix user that joined their channel (and you can translate that to XMPP or pretty much any other protocol Matrix is bridging to) is completely affected by these choice, pretty much against their will by design (not even talking about all the users who're not even aware about this).

And what do you want in a matrix related Issue?

This effects me because I participate in IRC networks that matrix bridges to. I never opted in to being archived publicly by Matrix, nor do I want to be.

@akierig It looks like the libera.chat rooms have history visibility set to joined which means the rooms won't be accessible in the archive at all (will just give a 403 Forbidden).
The archive bot will still join the room because it doesn't know the history visibility before it joins but it won't show any content from the room in that case (only world_readable and shared history visibility are accessible in the archive). If the public room is in the room directory, it will be listed in the archive but will still lead to a 403 Forbidden in that case.
It seems useful if we had an endpoint that would return the history visibility information without joining (GET /_matrix/client/v3/directory/list/room/{roomId} currently only returns whether it's in the room directory or not) . It would need to take a roomIdOrAlias instead to be useful though as that's the beauty of POST /_matrix/client/v3/join/{roomIdOrAlias} right now. It would also be nice to hide these rooms from the archive homepage as well which means /publicRooms would need to show the history visibility beyond the world_readable indicator it has now.

I would like to request increasing the priority for resolving this issue as there are currently at least two instances of bot requiring manual banning:

@archive:matrix.org
@matrix-public-archive:evulid.cc

Additionally I suspect the following of being matrix-public-archive instances:

@archive:privacyguides.org - I have no idea where its web interface is, but the homeserver admin is @jonaharagon who is active on this issue tracker and hasn't gotten back to requests for comment at Community Moderation Effort (or PrivacyGuides moderators haven't reported back hearing anything about him).

@Mikaela oops, I didn't see a question in CME. I do have this set up, but my instance can only join two specific rooms (which I admin), so it is not contributing to this problem.

For what it's worth, we've had to ban the archive bot on the bridge because it joined too many rooms. The IRC bridge (at least, the libera.chat bridge) requires that all Matrix-side users are joined to the IRC channels they are bridged to.
However, most IRC networks will limit how many channels one user may join at any time. The bot exceeded this value and the result was the bridge became very unstable. We're hoping there might be a solution to this problem at some point because I believe the archive provides value to some users of the bridge, but ultimately in it's present incarnation it's not suitable.

As there is even more development with opting more rooms into archiving, I would like to ask whether there is development also with opting out?
I also wonder whether this issue could be pinned for its significance? This tracker doesn't currently utilise that feature and three can be pinned at once on GitHub as far as I am aware of.
Additionally I have been wondering whether declaring Free Tibet and Slava Ukraini in public rooms gets them opted out from Baidu and Yandex?

I just learned that https://staging.archive.matrix.org/ is a thing and using a separate account @archiver:gitter.im and I find it upsetting that it's not mentioned anywhere and is again more whacking a mole while you could be better and allow rooms to just opt out of this "service".
You could be even better and be opt-in for room administrators which would be in spirit of privacy friendliness without even mentioning modern privacy legislations or directives.

I apologise for multiple comments in a row and heated emotions, but if  staging.archive.matrix.org is meant for internal testing/staging, why is it publicly accessible? Surely Matrix Foundation would have the resources to at least put HTTP Basic Auth in front of it?
I also question it having a different account. If the bot is truly stateless, why cannot it share the account so one ban would affect both instances?

@Mikaela there is absolutely no need to apologise. Not to mention that these are people not to be apologized. They are the one who should apologize general public.   I knew it from begining.

Doing a ban evasion with a second “testing” bot that is publishing data publicly isn’t the smartest thing to do.

I've also updated it to use the @archive:matrix.org user so there is no difference anymore. It was only historically using @archiver:gitter.im because MSC3030 wasn't supported on matrix.org while developing things.
The end-goal is to have staging.archive.matrix.org live behind some authentication. This is tracked internally by the deployment issue.

Currently Element gives room admins the option to make a room visible by "anyone" or "members only."  I don't see anything wrong with making a public archive of rooms that are readable by anyone already.
But the archive bot is joining rooms where the admins have already set the room to not be publicly visible, and it's archiving their history.  My room is set to be visible only to members, but the archive bot joined today and made the history visible on the public archive.  It's gone now, since I banned the archive bot, but I shouldn't have had to do that when I already "opted out" by setting my room to be not publicly visible.

Even if a room is publicly readable, that doesn't mean that its admins consent to conversations in that room being systematically scraped. Yes, anyone could come by and archive the room against the will of its participants. But this requires a targeted or coordinated effort.
I am very pro the idea of archiving Matrix rooms by the way. So much information gets lost on the internet every day because it got shared once in a Discord or Matrix or whatever room and will disappear with time. But this should be an opt-in process.
Make a UI element for it. Show people why they should have their rooms archived, make people care about archiving. Don't force this on people. Making privacy decisions for the user, not trusting them to understand what is best for them, is one of the ways that the tech industry has been eroding the trust of users over the last 20 years.
Please don't follow Silicon Valley's footsteps. It won't lead you anywhere nice.

I am very pro the idea of archiving Matrix rooms by the way.

Funnily enough it doesn't actually archive, it just makes search engines able to scrape the content, once the bot is banned, any content stored there is gone.

once the bot is banned, any content stored there is gone.

@Midou36O No its NOT gone once bot gets banned. Please stop spreading FUD.

I never used any Matrix products but I might be affected since I use XMPP and IRC. Can I request a listing of my personal data which is stored by Matrix under the GDPR?

@haansn08 Yes you can. There is official EU guide for rights, permissions, etc GDPR related.

@wojtekLs that page is not official, official EU domains are under europa.eu

@Mikaela ups, my bet. You're right 👍 BTW: Why your comment was marked as oftopic? Its on topic to its core.

Just an additional data point but is it considered that it may be a bad idea to allow anyone to activate this on any room? Shouldn't it be a thing only room admins can do? Basically because a) a room admin may not be aware of this b) a room admin may not want this but also doesn't want to clutter state with yet another ban.
Another thing is the right to be forgotten which exists in the eu. A user has the right to be forgotten as per gdpr. It's not clear how an individual can opt out even if the room itself is deciding to allow the bot. Mass redactions in the past have been the equivalent of a denial of service attack. So I don't think they are a sensible way to do this.

The GDPR thing is really important. Especially inside the EU people can really harm admins if a room gets archived against their will and they take legal action on this. A court would probably not have the knowledge to understand what this is and would blame the room admin or the server admin the room was created on for the fact that everyone's message gets archived (yes it's not really archived as in stored but archived as in search engines can scrape it). To be compatible with the GDPR it probably would have to be opt-in and opt-in on a user per user basis instead of a room per room basis. I as a room admin can never decide if all my users would be okay to have their (public) messages archived and scanned by search engines so I can't willingly take that decision. It would probably have to be so that I as a Matrix user can say "yes, archive all my messages I write in all public rooms per default, but don't archive my messages in room X Y and Z". This would only cause some part or contents of a room's conversation to be archived but it would be GDPR compatible because it'd be opt-in per user-basis.
I'm not a lawyer but GDPR can be good for users but very bad for service administrators. - Especially when those administrators can't really change it through to technical limitations or when I as an administrator are not even aware of a feature because it's not implemented with a notice inside the clients or the protocol itself.
Don't get me wrong I love the idea of public rooms being indexed by search engines so that knowledge can be shared in a better way and also archived for the future, BUT it's not good if some random user takes legal action against an administrator because of that at some point and this administrator then lands in a court without knowledge or technical understanding about this topic so the administrator get's eventually punished without any real reason.
-> Very hypothetical example but it's still possible IMO.

Very hypothetical example but it's still possible IMO.

@br4yd not so hypothetical. Very real Id say. Its entirely plausible and doable. You summed up exactly what I think on this. Just to add that, if one holds administrator position, one must know what GDPR is, its limitation/s etc. Hving no knowledge of law is not an excuse......

Additional complication with GDPR is that nothing prevents archiving the archive. From Forĝejo discussion on the bots:

view.matrix.org through waybackmachine
archive.matrix.org through waybackmachine

There are also other archives like archive.ph, view there.

@wojtekLs,

BTW: Why your comment was marked as oftopic? Its on topic to its core.

I try to keep the issue cleanish by selfmarking myself as offtopic when my comment is not strictly relevant to the issue at hand.


angular-bootstrap version 0.14.x and tooltip-append-to-body="true" causes vertical scroll bar to flicker.

Hi Guys, I have the scroll bar appearing and changing size issue for this new release angular-bootstrap version 0.14.2 when tooltip-append-to-body="true".
Plunker as follows:
http://plnkr.co/edit/HxTIllqhV0QSmDoZGtB3?p=preview

Closing as a duplicate of #4458.  Please search both open and closed issues before opening one.  For my part, I have been unable to reproduce this.

Hi @icfantv,
In the plunker i provided, i have tested with 0.14.2 and it seems to affect only when tooltip-append-to-body="true", so i am not really sure if it is a duplicate.

I still can't reproduce this.  What platform/browser are you using?

I don't see the problem either?  FYI, the example in your plunk, tooltip-append-to-body is set to false. I set that value to true and still didn't see the issue.

I updated the plunker. you need to:

resize your vertical height to a small size window
make sure you see the vertical scroll.
mouse over and out and over.

Did you see the scroll bar jumping?

Ok, I'm on a mac which hides the scrollbar after like 500ms which is why this is so hard to reproduce.  I can see it, but it's VERY hard to reproduce on a mac.
Additionally, this IS a duplicate of #4458 so leaving as closed.

@shenlong @icfantv I believe this is similar to #4458 with the fix being add top: -9999px and left: -9999px to the tooltip template style here.  Here is an updated plunk with those suggested changes.  Here is issue #4458's plunk with the same changes.

@RobJacobs, let's run that by @wesleycho and see if he's good with that.  TBH though, It smells like a hack to me unless this is an industry "standard."

It's a hack, but a well-known one...I don't have a huge opinion on it, and would be fine with it.

It's documented in ng-hide and TWBS uses it for the modal-scrollbar-measure class

Sounds good to me then

Works for me as well.  @RobJacobs you wanna make a PR?

Hi guys, thanks for the workaround. It looks good.
Background information: This existing issue is prominent when I am using ng-view with static headers. The vertical scrollbar only appears under the ng-view for overflow content. but having this bug will show another vertical scrollbar that appears at the header and since I did not style a slim scrollbar for the page, the re-flow of contents to accommodate 2 scrollbars width makes a annoying flickering.

@shenlong, just a head's up that we're committing a fix for this.  The PR is #4623 and should be merged either tonight or tomorrow.  So you won't necessarily have to implement a workaround on your end.

Hi icfantv,
Thanks for the heads up. I will prepare my bower for it! Hopefully get it asap as i need to implement the fix on my production site! Cheers!

@shenlong, you want npm and grunt, not bower.  In fact, don't use Bower anymore - it's kind of dying off.  Check out that git revision, run an npm install and then grunt and it will put everything in the dist folder.
Looks like that PR was merged so you should be good to go.

Hi @icfantv , my production server automatically bowers updates the "bower_component" folder. A gulp script then minifies and modify the link with CDN for production releases.
Will there be official version release for this?
Just curious how frequent do you update the release here: https://github.com/angular-ui/bootstrap/releases and the https://github.com/angular-ui/bootstrap-bower
Even though PR is merged, I need version tracking for third party framework.


Use new home for mDNSResponder

(cf. https://github.com/sony/nmos-cpp/pull/292)

Thanks @garethsb


Tags cannot be added to a listing

I was creating a listing and I tried to add a tag. Every time I try and add a character for a tag it is removed.  I am not seeing any errors in the console.  This is a showstopper since it is a required field.

Fixed by #326

All browsers
Verified that the develop allows tags to be added to a listing.

Verified in Staging that Tags can be added to existing and new listings.


Added delete environ command

gofabric8 now has a delete environ command.  Similar to the get environ command.

ok to test

Just a suggestion, and in general I believe it would be better to squash all the commits in one for the PR than multiple of them, (but I am not used that much to github worlflow so I may be wrong)

Just a suggestion, and in general I believe it would be better to squash all the commits in one for the PR than multiple of them, (but I am not used that much to github workflow so I may be wrong)

reckicked the test since the CI should be working now,

@chmouel happy to merge?

yep 👍
On Thu, 8 Jun 2017 at 18:34 James Strachan<EMAIL_ADDRESS>wrote:

@chmouel https://github.com/chmouel happy to merge?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fabric8io/gofabric8/pull/398#issuecomment-307157975,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGCpAfvO0FciUqNGm811djY5tk50li-ks5sCCJwgaJpZM4Nv3bB
.

I believe this can be closed!


Fixed search bug breaking code

@PassTheMayo What's the bug? Because the get method return the data from map.


Surround most text in a "usa-prose" component

Ticket
N/A
Changes
The typography on our pages doesn't match the designs in general:
everything fees cramped with a short line-height and different
font-size. Upon further inspection of the USWDS page templates, most
body content is in a "Prose" component, which makes the text a bit more
readable.
This commit surrounds all the text in a "usa-prose" component.
It also updates the styling of the  with the consent, since there
was an extra large bottom margin due to the .
I didn't touch the payment details page, since Matt is concurrently
refactoring the whole thing.
Context for reviewers
I paired with Carmen and she thought this was a good idea.
Testing
I will record going through the flow for acceptance testing by Carmen.

@carmenrosalop Here are before / after screenshots of every page in the flow. (Before is on the left.) Please advise if you see anything strange. The main weirdness to me is that the homepage text is kind of narrow, but to me it still looks ok and better than it was before.


Optimisation of BufferedRows

Hey, I saw that the BufferedRows shouldComponentUpdate always returns true and PureRenderMixin should not be used. Is there a reason why?
Thanks ;)

Adding PureRenderMixin means it will never update - if you try it, the table just sits there completely stationary :p

Ah ic, are there any ways to optimise a single row not to update, such as when the data is really the same.

That is actually how the table works right now! The rerender of s cell is determined by the results of the rowGetter or the cellDataGetter.  It'd be great to see if its something that we should address.

Ah nope, was just thinking if i could make my application even faster :P But the current one works great and scales. (Y)

Great to hear it! If you don't mind I'm going to close this issue then - feel free to open it if anything changes.

@ehzhang hmm seems the lag does occur. Basically I'm using rowEnter and rowLeave to set a border bottom to the row, by setting a state and customising handleRowClassName.


[BUG] Logos is unable to recover because of whitespace

Not exactly sure how to title this issue or how to describe this bug. I'll present you the following enum:
#[logos(skip r"/\*([^*]|\*[^/])+\*/|[ \t\n\f]+")]
pub enum Metadata {
	#[regex(r#"[a-zA-Z][a-zA-Z0-9]*[\s]*:[\s]*[^:;][^;]*"#, |lex| split_to_twople(lex.slice(), ':'))]
	Map((String, String)),

	#[token("include")]
	Include,

        #[token(";")]
        Semi,

        #[regex(r"[a-zA-Z]*(::[a-zA-Z]*)+", |lex| lex.slice().to_string())]
        Path(String),
}

Given the input string: "include some::path" this will make the lexer return an error.
Some explanation of the enum. The regex for Map describes a key: value pair. The key must be alphanumeric. The value can be anything. Each pair is terminated with a semicolon. The paths are Rust style paths import paths. You can ignore the split_to_twople method. It returns a specific error in case of failure, as opposed to the generic error that is being returned by the issue. We can be sure that's not where the error lies.
Through experimenting, I have found that removing the [\s]* to the left of the : in the Map regex fixes the issue, but as a result, you are no longer able to do key : value, which I would like to still lex.
It seems like somewhere, after it has tried the whitespace and then fails on the : it is unable to recover and try other valid lexes (in this case, include).

Hello!
Did you try without the whitespace? Your skip regex is quite complicated, but I guess it should match white spaces. Maybe you can try with a simple skip whitespace regex (so remove other tokens) and see if it works.
In general, you regexes seem overly complicated for what they should achieve. Also, I am not sure you should put \s inside [] for white spaces matching. Maybe simplifying your regexes can first help.

Update, simplifying the regex to [a-zA-Z][a-zA-Z0-9]*\s*: gives the exact same issues.


Oracle Cloud Infrastructure provider

Looks good, we'll merge this after https://github.com/opencost/opencost/pull/2367 lands in a release


Helm profiles confusing users to put their own config under defaults

See https://blog.howardjohn.info/posts/advanced-helm/
I have seen a few people putting all their config under defaults. This is not how its supposed to be done; defaults was meant to be internal. We may need an alternative approach to solve this, or improve docs.

In general, values.yaml is supposed to be documentation, and in fact most helm autogenerated doc tools treat it as such - it's the source of truth for valid keys in a Helm chart. The key-value pairs in it are supposed to be directly settable, and that will always be the expectation, because that is how Helm works.


Error connecting to the service protocol

So I am not exactly a complete newcomer to Flutter, but I do have many gaps in my understanding of how all of the pieces fit together.  Regardless, I am trying to increase the complexity of my apps and I liked the work you have done in this repo and wanted to learn from you.
I have run into an issue which is outside of anything I have previously encountered in Flutter and so far my Google searches to resolve the problem have not been very helpful.
SUMMARY: When I try to run your app with only the minimal changes required to allow it to connect to my instance of Firebase, it flashes a white screen for a brief moment and then exits.  I am seeing the same behavior on my Android emulator and my physical Android device (I have not attempted on ios).  The following are the last 4 messages displayed in the debug console each time I attempt to run:

Tried to automatically register plugins with FlutterEngine (io.flutter.embedding.engine.FlutterEngine@7d866ec) but could not find and invoke the GeneratedPluginRegistrant.
Attaching FlutterEngine to the Activity that owns this Fragment.
Error connecting to the service protocol: failed to connect to  http://<IP_ADDRESS>.1:63924/s8uwxXhoRuU=/
Shutting down VM (on the physical device it just hangs)

I am assuming this problem is related to how my environment is setup to handle plugins and I am totally unfamiliar with how plug ins are setup/developed/deployed.
I have done the normal flutter clean / doctor / build routine to see if that would help.
I would appreciate any insight or suggestions you may have.
Flutter: 1.12.13_hotfix.9 - stable channel
Windows 10 development environment

UPDATE: I saw something in LogCat which seemed to indicate there was an issue with the Facebook authorization.  I commented out all Facebook and Apple references and the APP now runs as expected.
This will allow me to move forward.  Somewhat defeats the purpose of a multi-auth template but I can re-visit when I either hear from you or, I gain more experience with those providers.


Update troubleshoot docs: HMR not working in wsl2

Is your proposal related to a problem?

I recently upgraded from wsl1 to wsl2 and after figuring out for a few days, I realise that HRM doesn't work in wsl2 (see https://github.com/microsoft/WSL/issues/4417 and https://github.com/microsoft/WSL/issues/4739).
Describe the solution you'd like

Initially I thought it might be an issue with webpack dev server but turns out it was because of wsl2. As @viltiki813196 suggested in https://github.com/microsoft/WSL/issues/4417#issuecomment-647254919, I too think that this document needs to be updated to highlight this issue. There doesn't seem to be any best solution for now, so switching back to wsl1 until HRM for wsl2 is fixed is my only solution so far.
What do you guys think?

You can move your files outside of mnt/ and put it in Linux file directory to use WSL2

@gjj also you can put CHOKIDAR_USEPOLLING=true in the scripts, but this make a high use of CPU

@estiventhneira thanks! I eventually switched to a Mac because I'd rather not fight with Windows everyday. For those who would still be using WSL, maybe they could try the CHOKIDAR_USEPOLLING method.


Updating all jersey URL's to new Jersey home

java.net site has closed. Updating all jersey URL's to new Jersey home.

Coverage remained the same at 84.524% when pulling c698450092f4c4fd3e7850ebf8a1f4d866869882 on sankate:master into e2756757075ac8e11f21267a93d7fb1f2270c53d on dropwizard:master.

Awesome, thank you so much!


popover close button

how i can close popover with button and code?
thanks in adv

is this issue solved ?


chore: fixing sol warnings

Please read contributing guidelines and remove this line.

#10276  👈 (View in Graphite)
master

This stack of pull requests is managed by Graphite. Learn more about stacking.


Add do notation support (bind, bindW) for TaskThese

🚀 Feature request
Current Behavior
TaskThese lack do notation support
Desired Behavior
It would be great if do notation (bind, bindW, bindTo) could be extended to TaskThese.
https://gcanti.github.io/fp-ts/guides/do-notation.html
Suggested Solution
Implement bind, bindW methods similar to TaskEither
Who does this impact? Who is this for?
Scenarios where you keep track of minor errors/warnings
Describe alternatives you've considered
Using chains and maps, but the syntax is quite verbose

I basically see why it is not feasible to implement this at the current stage. Depending on the use case it is possible to implement it for a given Semigroup, but this makes me wonder:
Generally speaking: If you chain multiple Both, wouldn't you always want to accumulate the lefts? Treating These as with the notion "compute as far as you can", it makes sense to accumulate lefts in some structure. In my opinion it is easier to get the first / last left for cases where it is desirable, then to go through a lot of hoops in order to implement this accumulating behavior.


chore(main): release 1.3.6

:robot: I have created a release beep boop
1.3.6 (2023-03-28)
Styling

Format code with prettier (c7d3d19)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/School-of-Website-Engineering/future-front-end/releases/tag/v1.3.6 :sunflower:


make golint happy about the congestion tests

Codecov Report

Merging #1201 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1201   +/-   ##
=======================================
  Coverage   91.11%   91.11%
=======================================
  Files         114      114
  Lines        7729     7729
=======================================
  Hits         7042     7042
  Misses        461      461
  Partials      226      226

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c65b1ac...6fcdcdb. Read the comment docs.


Fix hooks test

Codecov Report
Patch and project coverage have no change.

Comparison is base (922a70a) 100.00% compared to head (cefe03e) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #19   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            4         4
  Lines          331       331
  Branches        64        64
=========================================
  Hits           331       331

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


How does the filter argument work?

How can I filter to exclude two hosts (wikipedia.org and facebook.com)?
According to the docs, filtering is done via -f argument.
'-f', filter results [url, title, text, host] is what I find in the script.
As -o json will output to JSON and is described as '-o', help='output file [html, csv, json]', I expected something along the lines of -f host REGEX but does not work.

The -f argument is somewhat similar to the advanced search operators of Google. The difference is that it doesn't accept a value, the value is the search query. Also, the filter is inclusive and it doesn't accept regular expressions. For example, if the search query is "query" and the filter is "url", only links that contain "query" in the URL will be collected - it would be equivalent to Google's  advanced search operator "allinurl: query". If you think this feature can be improved, you're very welcome to contribute, or I may do it myself when I have some free time.


Database Exception Error Fetching enum values

Environment
Liquibase Version: 4.19.0
Liquibase Integration & Version: Spring Boot 3
Database Vendor & Version: MySQL 8.0.30
Description
During the build process an exception is thrown for enum declared columns
in the class ColumnSnapshotgenerator, line 425
with the following output:
liquibase.exception.DatabaseException: Error executing SQL SELECT DISTINCT SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING(COLUMN_TYPE, 7, LENGTH(COLUMN_TYPE) - 7 - 1 ), "','", 1 + units.i + tens.i * 10) , "','", -1)
FROM INFORMATION_SCHEMA.COLUMNS
CROSS JOIN (SELECT 0 AS i UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) units
CROSS JOIN (SELECT 0 AS i UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) tens
WHERE TABLE_SCHEMA = 'my_table_schema'
AND TABLE_NAME = 'InfoContent'
AND COLUMN_NAME = 'Type'
ORDER BY tens.i, units.i: Expression #1 of ORDER BY clause is not in SELECT list, references column 'tens.i' which is not in SELECT list; this is incompatible with DISTINCT

This is the corresponding column definition
<column defaultValue="DEFAULT" name="Type" type="ENUM('DEFAULT', 'PRODUCT_API')">
                <constraints nullable="false"/>
</column>

Is the column definition wrong or is something missing?

Hi! We dont support the column type enum as you can see here  if you want to create or manipulate a column with enum type you should do a use the sql change type. Thanks for submittion this issue. In case this doesnt help let us know, I will leave this issue open until then.

Does that mean you don't support ENUM columns when running the generate-changelog command either?
If I run a liquibase generate-changelog against my MySQL database, I get output similar to the following for ENUM columns:
            <column name="status" type="ENUM(11)">
                <constraints nullable="false"/>
            </column>

.. when it should be:
            <column name="status" type="ENUM('FAILED', 'CANCELLED', 'INGEST', 'IN_PROGRESS', 'COMPLETE')">
                <constraints nullable="false"/>
            </column>

Based on this very old thread, it was supposedly fixed in version 3.0.8 - has it regressed? Or is this a new bug? Or is this be design for some reason?
Thanks.

I created the enum column with a native SQL statement
 <changeSet id="addEnumTypeColumnForInfoContent" author="tina">
        <sql>ALTER TABLE InfoContent
            ADD COLIUMN Type ENUM('DEFAULT', 'PRODUCT_API') DEFAULT 'DEFAULT' NOT NULL</sql>
    </changeSet>

The column is created correctly
But the database exception from above still occurs.

It looks like you are right and this is indeed a bug. I will add it to our queue of issues to fix. It can take a while to fix, now that you have an idea of what could be happening, can you submit a PR with a fix? This will speed up the process and we will help you through it. Thanks!

Came here to see if this had been raised. Seeing the same thing fieldName ENUM(10) NULL,  over the correct values

@FBurguer I made some quick changes, but I'm not really across the expected operation of this or JAVA. Not sure why you'd want to reforge the string when MySQL provides in in the correct enum('value1','value2') format.
I haven't built or tested as i don't have time to learn to build the java right now. But hopefully someone with experience can
https://github.com/liquibase/liquibase/pull/3832/files

It looks like you are right and this is indeed a bug. I will add it to our queue of issues to fix. It can take a while to fix, now that you have an idea of what could be happening, can you submit a PR with a fix? This will speed up the process and we will help you through it. Thanks!

Had a second go and fixed this up. It is working in generateChangeLog for me
https://github.com/liquibase/liquibase/pull/3842/files

Looks like this was introduced in #3150
I reverted to 4.10.0 and I don't have the issue (but the sorting is indeed wrong).
@nwcm have you tried removing the entire if block? I don't know the code well, but it seems like the MySQL workaround that was needed 10 years ago (https://github.com/liquibase/liquibase/commit/fa6cd1d5413d51749ce05edb6c79f60d12784daf) is no longer needed. But not sure since enum isn't standard what else is needed. https://liquibase.jira.com/browse/CORE-1224 implies it was needed at least as late as MySQL 5.5. But http://download.nust.na/pub6/mysql/doc/refman/5.5/en/enum.html implies that it should have worked without this strange workaround.


Should setting baud rate for serial communication be part of this hal?

I believe some way to set baud rate for the serial traits is needed.
Relevant problem
Dynamixel servos comes with two different RS-485 protocols that have some difference in support of baud rate. And even if every servo on your RS-485 bus uses the same protocol there should be nothing stopping you from configuring them with different baud rates. This require setting baud rate before communicating with a servo.
This is currently the biggest blocker for having the dynamixel library work for every embedded-hal implementation out of the box (as it currently does with adapters supporing serialport)

One possible solution could be to introduce a serial::Serial trait that implements the set_baud_rate(&mut self) -> Result<(), Self::Error>.
Then i could auto implement the dynamixel interface for Serial + Write + Read types

Hm, so you're using the Serial trait for RS-485 communication? Interesting. Is this application relying on the fact that a RS-232 to RS-485 adapter is available?
I do agree that there're some uses for on-the-fly configuration changes, so I'd be very much in favour for adding this; however we'd need to check for implementation feasibility. There might be chips which only allow such changes through full re-initialisation which may require resources which are not owned but only borrowed.

Hm, so you're using the Serial trait for RS-485 communication? Interesting. Is this application relying on the fact that a RS-232 to RS-485 adapter is available?

currently I've only implemented it for this serial trait. I've tested it with an ftdi like rs485 usb dongle.
You could use a RS-485 transceiver directly connected to some uart, meaning it's no need for converting to RS-232. Since this is SW and we don't really care about things as differential-lines and voltage levels the only real difference is that with RS-485 is that you cannot read and write at the same time.

@kjetilkjeka That only works with dedicated hardware. When using a MCU and a RS485 transceiver you will need a "Driver Enable" signal. Expecting the user to manage that manually is not very user friendly and some chips, e.g. STM32 MCUs have hardware support for it which is especially handy if one wants to use async IO.

The simple way is to connect tx together with the enable line. Then you will get dominant 1s and recessive 0s. That is if the mcu doesn't drive the enable line for you.
I would expect the write/read implementation to handle this. If they don't they're pretty much useless. I'm not suggesting such a thing.

My point is that you'll need specific setup for that case. You can't just use the regular serial impl and it'll work out automagically for RS-485 as well.

Is this simply an observation, an argument against adding the set baud method or an argument against using the serial traits for RS485?
Perhaps I'm wrong, but i see the serial traits as a generic serial protocol. Much like the stdlib Read/Write traits can be used on network sockets, files, rs485, etc. I expect the serial traits to work on uart, usart, RS232, RS485, etc. Even for the simple uart case you will need "specific setup" as voltage levels might not be the same for the commuinicating units.

It's a somewhat unrelated observation that the serial trait may be lacking more details than just the baudrate selection to be useful for various serial protocols.

I'm in favor of keeping the base Read and Write traits as simple as possible -- they should have to do with transmitting and receiving bytes on the bus, and basically nothing else.
However, I can also see the need for changing the baud rate (and possibly other parameters) at runtime. I'm going to make the same suggestion we've talked about elsewhere: Add a separate, but composable trait (maybe serial::Configure). Something like:
trait Configure {
    type Freq;

    fn set_baud_rate<T>(&mut self, baud_rate: T) where T: Into<self::Freq>;
}

This doesn't break existing implementations, and leaves it to implementers to decide whether such configuration makes sense for their use-case.

This is a rather messy topic and I don't have good solutions in my head at this time. Your "standard" baud rates are ending far too low, 115200 is rather pedestrian nowadays. Also even "standard" baud rates can very often not be represented exactly and also often this depends on the clock the UART or even the whole system is running at.
For me this means it either should be fallible or there must be a way to determine whether a baud rate can be supported or what the next closest supported value would be.

This is a rather messy topic and I don't have good solutions in my head at this time. Your "standard" baud rates are ending far too low, 115200 is rather pedestrian nowadays.

These are BaudRates that every unit conforming to the embedded-hal needs to support. And it looks like Rust is going to work on 8-bit avr in the future. Perhaps this is a good argument for dropping the infallible set_baud.

Also even "standard" baud rates can very often not be represented exactly

How big of a problem is this? I would be happy with the "best effort" and "you should probably have your impl fail if it's to far away (2-3% or something)"

and also often this depends on the clock the UART or even the whole system is running at.

I guess the solution here is, If the implementation don't know what kind of freq the uart clock runs at this Trait should (read: can) not be implemented.

This alternative would supporting getting an indication of how much off the BaudRate is. But would allow scary things like. interface.set_baud_rate(BaudRate.closest(9999999999)) (the naming is ad-hoc)
#[derive(Debug)]
pub struct UnrepresentableBaud;

pub trait BaudRate: Into<f32>{
    //// Try to crate a `BaudRate` with less than 2% error.
    fn create_approximately(baud_rate: u32) -> Reult<(), UnrepresentableBaud>;

    //// Create the closest `BaudRate` possible to `baud_rate`.
    fn closest(baud_rate: u32) -> Self;

}

pub trait ConfigureBaud {
    type BaudRate: BaudRate;

    fn set_baud_rate(&mut self, baud_rate: Self::BaudRate);
}

These are BaudRates that every unit conforming to the embedded-hal needs to support.

Huh?

And it looks like Rust is going to work on 8-bit avr in the future.

Even the ominous ATMega328 officially supports 2 MBaud...

How big of a problem is this? I would be happy with the "best effort" and "you should probably have your impl fail if it's to far away (2-3% or something)"

It's a big problem. I've seen people clock their MCUs specifically for proper serial communication and if this is all automagic then it will cause all sorts of surprises.

I guess the solution here is, If the implementation don't know what kind of freq the uart clock runs at this Trait should (read: can) not be implemented.

Well, often you pass in the relevant clocks when initialising the UART, e.g. from the stm32f103xx-hal:
            impl<PINS> Serial<$USARTX, PINS> {
                pub fn $usartX(
                    usart: $USARTX,
                    pins: PINS,
                    mapr: &mut MAPR,
                    baud_rate: Bps,
                    clocks: Clocks,
                    apb: &mut $APB,
                ) -> Self

So the application sets up the clocks and passes it in so there's no way of knowing whether the baud rate is compatible with the current clocks and now coming back to this topic and my previous concern: If you reconfigure the baud rate on the fly you will most likely have to pass in the very same information again that was used during construction to make the proper calculation (and some chips actually require that you turn the peripheral off again to make such a change) but this is all implementation dependant...

So it looks like the temporary spec sheet currently looks:

Configurable baud rate must not be a requirement to use Write/Read.
Support weird baud rates.
Give an indication of how far away from the desired baud the actual baud is.
Be explicit whether you need an "exact" baud or approximate baud.
Be explicit of when the baud rate change occurs (can this affect bytes already called transmit on?)
Must not require passing any "init" information like uart clock frequency etc.
Of course, be easy to use correctly and hard to use wrongly.

and some chips actually require that you turn the peripheral off again to make such a change

If this is the case, the reconfigurable baud rate should probably not be implemented (or handle these special concerns in software)

So the application sets up the clocks and passes it in so there's no way of knowing whether the baud rate is compatible with the current clocks and now coming back to this topic and my previous concern: If you reconfigure the baud rate on the fly you will most likely have to pass in the very same information again that was used during construction to make the proper calculation

I guess what you mean is "no way of knowing statically"? As the interface could remember its clock frequency. Then you could simply ask the interface whether the new clock freuquency is compatible or not. For instance with:
#[derive(Debug)]
pub struct UnrepresentableBaud;

pub trait ConfigureBaud {
     fn set_baud_rate(&mut self, baud_rate: u32) -> Result<(), UnrepresentableBaud>;
}

I guess what you mean is "no way of knowing statically"? As the interface could remember its clock frequency.

The problem with "remembering" is, that the clock might actually change...
At the moment, the most compatible and safest way to change the baud rate would be to drop and reinitialise the serial interface.

The problem with "remembering" is, that the clock might actually change...

If the clock changes the current baud rate would also change, therefore needing interaction with the serial implementation (hw driver), this should be used to update the remembered value. If, for some weird reason, the baud rate is controlled by unkown external factors the ConfigurableBaud trait cannot be implemented for that controller.

At the moment, the most compatible and safest way to change the baud rate would be to drop and reinitialise the serial interface.

Since initialization is not the responsibility of this hal this would make it impossible to implement the dynamixel protocol generically for devices supporting this hal.
@therealprof if an implementation was made adhering to my "temp spec sheet" would that be something you would consider to include in the hal (and are there any other concerns that must be made), or would you prefer keeping baud rate configuration out of the hal at the current being?

Since initialization is not the responsibility of this hal this would make it impossible to implement the dynamixel protocol generically for devices supporting this hal.

True.

@therealprof if an implementation was made adhering to my "temp spec sheet" would that be something you would consider to include in the hal (and are there any other concerns that must be made), or would you prefer keeping baud rate configuration out of the hal at the current being?

As I mentioned before I think it would be useful to have and thus don't have any general objection to include it.
However we need to ensure that the traits are designed in a way that they actually can be implemented in a safe and sane way on common hardware and at the moment I don't see that how that would be possible.

Another relevant problem:
More than one device that uses an UART interface supports changing the speed on the fly. Usually they start at a low baud rate, and then you can select a higher one by sending a command via the UART. After that you need to switch your end to the higher baud rate too.
Currently there is no way to do this with an embedded-hal serial driver.

Somewhat related: mpu9250 (accelerometer & gyroscope sensors) allows using SPI configured at 1Mhz to read/write configuration register, but up to 20Mhz to retrieve readings. To account for that, we've added ability reinit spi after initialization, but it could be easier if embedded-hal provided methods for updating configuration.

@little-arhat How would you do this safely? A method on an embedded-hal trait can not contain any of the information usually required to do such a change and for most MCUs it can also not be stored in the implementation since it might require access to shared registers.

@therealprof that what this issue is about, I guess: should embedded-hal include methods like set_speed(bps) or set_bus_frequency(hz).

@little-arhat And my question was: Are those methods even (safely) implementable? I have strong doubts that they are (in general at least)...

@therealprof I don't know, but do they have to be safe?
For example, this hal implementation has buncf of unsafe calls in Watchdog, OutputPin, InputPin, and maybe others.
On the other hand, stm32 HAL doesn't provide such functions.

@little-arhat unsafe does not necessarily mean that something is not safe but that the compiler can not reason about the safety by itself so it's up to the software author to do that.
Anyway my point is that for a "safe" implementation you actually need to have exclusive access to the resources you're changing to not stomp on someone elses feet. Usually that means that you have to provide mutable references to every resource required to set up the peripheral in the first place which is typically very unwieldy and thus not expected to happen in the middle of a running application but during initialisation. Also due to the very different nature of the vendor peripherals this is not something that can be easily abstracted over in the vendor independent way which makes it highly unsuitable for embedded-hal.
If someone can show a convincing demonstration that this can be generically defined in a trait and usefully implemented for any real hardware I'd be more than happy to help turn it into an extension trait.

I'd like to bring this back up.
I have a device that does auto baudrate detection, but only up to 115200 bps, so in order to run it with a higher baud rate, one would have to:

Auto baud @ < 115200 bps
Set device baud rate to > 115200 bps
Reconfigure UART peripheral to baudrate from point 2

I would like this logic to be contained within the drive crate, thus i need a way to reconfigure the baud rate after initial initialization of the UART.

How does a trait like this look?
pub trait ConfigureBaud {
    type BaudRate;
    type Error;
    fn set_baud_rate(&mut self, baud_rate: BaudRate) -> Result<(), self::Error>;
}

Many of the current hals have their own type for baudrates, so giving them the oppertunity to use them makes sense and gives them the responsibility of supporting 'weird' rates.
Having the option of returning an error you can limit the available bauds to the ones compatible with a given clock setup or else return an error.
As a response to an earlier issue, if a given clock setup changes and there are not made a way of updating the copy held by the Serial interface. The Serial interface baud is lost anyhow.

For e.g. HC-12 serial transceiver module, this would make it possible to change the baud rate (which the module requires for supporting all modes).

Another case in point is using a USART as 1-wire Bus "master". There you need to frequently change the baud rate in order to generate the correct bit patterns.
I think the trait proposal by @unizippro looks good -- note that the BaudRate type used by the implementation could encode information about the clocks if needed, which allows to erase that dependency from the general trait interface.
In addition, I suggest to make the function return nb::Result, in order to allow the impl to wait for an ongoing transmission to complete or any other precondition necessary to change the baud rate.

How does a trait like this look?

pub trait ConfigureBaud {
    type BaudRate;
    type Error;
    fn set_baud_rate(&mut self, baud_rate: BaudRate) -> Result<(), self::Error>;
}

seems broadly good to me.

from an end-user perspective imo it's better to use an u32 value for baud rate, otherwise you have to add a bunch of complexity to abstract over the BaudRate type
i'd be inclined to return the actual baud  instead of () on success to let users know what was achievable with the oscillators available (it's normal for there to be a slight difference between requested and actual bauds due to clocking).

if you would like to contribute this i would suggest going forward with an e-h and demonstration PR, any further trait-specific discussion can occur there ^_^

I'd just make baudrate an u32, or some Hertz concrete type.
Having an unconstrained type BaudRate seems like the same mistake in #324, https://github.com/rust-embedded/embedded-hal/issues/201, https://github.com/rust-embedded/embedded-hal/issues/177#issuecomment-910396479 . Different HALs will use different types among u32, whatever Hertz they have, or stuff from embedded-time or similar, making the trait impossible to use from HAL-independent drivers.

I have to agree with @ryankurte that this should be fleshed out in a demonstrator PR. I still have strong doubts this is generally implementable without gnarly hacks but would love to be proven wrong.

I implemented a similar trait as PoC based on the stm32f1xx-hal. I had to use the unconstrained (custom) BaudRate type to force the user to go through a function which calculates the correct register value from the current clocks. The Serial in stm32f1xx-hal is mostly a zero-sized type and does not hold a reference to the (frozen) clocks.
It looks roughly like this:
pub trait AsyncSetBaudRate {
	type Error: Debug;
	type BaudRate;

	fn poll_set_baud_rate(
		&'_ mut self,
		rate: &Self::BaudRate,
		cx: &mut Context<'_>,
	) -> Poll<Result<(), Self::Error>>;
}

pub trait BaudRateGenerator<T> {
	fn calc_baud_rate(&self, bps: u32) -> T;
}

#[derive(Clone, Copy)]
pub struct BaudRateConfig {
	config: serial::Config,  // serial from stm32f1xx_hal
	clocks: rcc::Clocks,  // rcc from stm32f1xx_hal
}

pub struct BaudRateFromClocks<'x>(pub &'x rcc::Clocks);

impl<'x> usart::BaudRateGenerator<BaudRateConfig> for BaudRateFromClocks<'x> {
	fn calc_baud_rate(&self, bps: u32) -> BaudRateConfig {
		BaudRateConfig {
			config: serial::Config::default().baudrate(bps.bps()),
			clocks: *self.0,
		}
	}
}

(sorry, I'm a bit in a hurry right now so no proper minimal test code)
I'm not convinced this is the best design (for instance, this is not actually calculating the BRR register value and storing it in BaudRate, but instead only putting the necessary values to call reconfigure on the Serial), but it was possible to implement this without modifying stm32f1xx_hal.
To improve the implementation, I would've had to modify stm32f1xx_hal to support setting only the baud rate and to provide a wrapper type around the register's integer type in order to allow precalculating that value from frozen clocks.
Without that, the trait would indeed force the Serial implementations to know about the current clock rates, which sounds painful at least.

I had to use the unconstrained (custom) BaudRate type to force the user to go through a function which calculates the correct register value from the current clocks

If calling the trait needs calling HAL-specific methods/types, it can't be used from HAL-independent drivers. With this design, set_baud_rate might as well be an inherent method in Uart instead of a trait method, since the advantage of having traits is writing HAL-independent drivers, and this trait is not fulfilling that.

the trait would indeed force the Serial implementations to know about the current clock rates, which sounds painful at least.

embassy-stm32 stores the current clocks in a global, so Uart/Spi/I2c/etc have access to it at all times. WIth that design it's possible (and not painful at all) to implement a trait like fn set_baudrate(&mut self, baud_rate: u32), which would be useful for HAL-independent drivers (no unconstrained BaudRate type)


juanpicado: "Well, perhaps we should improve documentation."

Omg, yes please!
This cost me so much time, just because the documentation doesn't say anything about this :D
--> https://github.com/verdaccio/verdaccio/issues/698

About what? Please improve the issue title and description so we know what is about?

and to rephrase the "We" ... 🙃 I refer to anyone.
Docs are here: https://github.com/verdaccio/website
Translations are here https://translate.verdaccio.org/


Make ComponentsFormatterOptions init public, fixes #653

I just saw that there already is a commit to fix this. Closing.


mismatch with some predefined nginx location rules

it is impossible to open in jenkin scanned "reporting-service" folder.
it redirects onto the zebrunner insights (zafira) instead:)

closing as dupe of https://github.com/zebrunner/zebrunner/issues/212


Popover Outside Click Firing if bind:open is set to variable

Describe the bug
This one is really odd, if you set the bind:open to a variable like let open: boolean = false, the outsideClick stops working and considers any click inside of content to be an outside click as well.  This is very problematic if your using this control for a menu and there are links in it because it cancels those link clicks as well.
Reproduction
Setup the popup, create some content add a link to that content.  Then in you script tag setup a variable called open, and bind:open to it in root.  Now when you click in the content, it fires OnOutsideClick event. You can verify the behavior by attaching to the OnOutsideClick event, and also by calling event.preventDefault() inside that will prevent the popup from closing and the links internally work.
Logs
No response
System Info
n/a

Severity
annoyance

Not able to reproduce this.

Ok, I'll throw together a quick repro as even stripped it down to bare bones in my project and it's still happening. So all that was left was the basic structure, no other components and it behaved like this...

You shouldn't have to hack it, what you're describing (if can be confirmed with a minimal reproduction) would in fact be a bug! I just need to see it happening to determine where the cause is and such.

I could not get this to reproduce in StackBlitz, but I recorded a short video of my code showing how simple it is and the behavior I am seeing.
https://github.com/huntabyte/bits-ui/assets/217424/50d1a28a-bb07-4b2a-bc5e-ed2b71bc4184

You're binding a bunch of Popovers to a single open state. When you click outside one of the popovers into another of course the others are going to fire an outsideClick. When you bind that outside click in one popover is going to set it to false meaning it closes the others.


feign client http header can not use json string as header value?

Describe the bug
I need to use feign client to make a RPC invoke and use a json string value as http header,
but I find feign.template.Expressions#create use ":" to split my json string and only use part[0], part[1] to make an Expression.
for example: "{"source":"Inner", "traceld":"0b34769c298dccc7e1b0a548"'" as a input header value finally we only get
"{"source":"Inner", "traceld"}"
the version I'm using is : spring-cloud-starter-openfeign:3.1.8
Sample
for feign client http header key-value
common_header: "{"source":"Inner", "traceld":"0b34769c298dccc7e1b0a548"}"
but receiver only cat receive:
common_header: "{"source":"Inner", "traceld"}"

Hello, @Gavin16. Spring Cloud OpenFeign 3.1.x is no longer under maintenance. Please upgrade to 4.0.x or 4.1.x. Also, the relates to RequestTemplate that is part of the OpenFeign/Feign project and not SC OpenFeign. You can start a discussion on it there.


[LAB1]312555016

[x] A clear title (name your pr "[LAB{lab_number}] {your_student_id}")
[ ] A meaningful message for PR, as well as its commits
[ ] From your specific branch (not main or other's branch) merging to your branch
[ ] Excluding any irrelevant files, such as binaries, text files, or dot files
[ ] Passing tests/CI

Remember to follow PR title, checklists' rules. Also, you should leave meaningful messages in your commits.


Rendering issue of FieldRowPanel inside MultiFieldPanel

Issue Summary
There is extra top-padding when rendering a FieldRowPanel inside a MultiFieldPanel in the admin - since #5707.
Steps to Reproduce
Create a model with the following panels:
panels = [
    MultiFieldPanel(
        [
            FieldRowPanel([
                FieldPanel('field1'),
                FieldPanel('field2'),
            ]),
            FieldPanel('field3'),
        ],
        heading="Collection of Fields"
    ),
]

Technical details

Python version: 3.7.6
Django version: 3.0.4
Wagtail version: 2.8

Merged in via #5905


feat(menu/VirtualTemplateIED): automatically create virtual IEDs

This is it, the plugin that allows to automatically create a virtual template IED - name SPECIFICATION - based on the function structure in the substation section.
I decided to pack it into a menu type plugin for not. When we will extend the functionality around the virtual IED creation in the future, we can convert it into an editor type plugin.

To test, use the *.ssd file in the testfiles folder.

Closes #742

Thank you for this opportunity to provide comment :+1:
I thought I'd do an initial usability test and fiddle around.

The first thing I did was enable the plugin and try to create an IED without any functions or subfunctions present. I had a valid Save button which did nothing.

Eventually, I remembered to follow the instructions and look at the SSD file and then saw a list of LNs but I think either a message to the user and/or a greyed out button might be appropriate.

It feels very odd to me to have a toggle button which functions as a check box for LN0. Is this to indicate that this is mandatory or recommended? I think this is here to ensure that a LDevice always meets at least one mandatory LN0 if it not specified in the Function breakdown...

After creating a virtual IED, I thought, "I wonder what that did?" and looked at the IED editor to find an IED exists but with nothing in it? I was using /test/testfiles/zeroline/functions.scd which I realise is the incorrect file but it was a fun test.

In Pro Mode when I examine the source all I see is the container.

I'm not sure if I have erred in some way. I do not have any console errors.

Finally using the correct file in test/testfiles/virtualied/specificfromfunctions.ssd I am able to create an IED with LNs! I note that if I don't select a checkbox I can't create an IED but receive no error message (I think there should be some indication to the user as to "why it didn't work").

I notice the XML is not pretty-printed for this IED when I click edit in the IED editor. Probably out of scope for this PR I know unless it was to do with the way the elements were added to the document. However most 61850 SCL tools pretty-print output.

I will study the standard and then play some more in a little while. These comments are me fumbling around and being pernickety :wink:

Thank you, @danyill, for your valuable inputs. Based on your findings, I would suggest to make two changes:
1.) Save button should be available only if a valid virtual IED can be created
2.) I would replace the radio button with a select field for LLN0 type logical nodes. I think it makes it clearer for the user that there must be something - only one - LLN0 reference. It also differentiates better to the checkbox used for other type of logical nodes.
What do you think about that?

1.) Save button should be available only if a valid virtual IED can be created

Sounds good.

2.) I would replace the radio button with a select field for LLN0 type logical nodes. I think it makes it clearer for the user that there must be something - only one - LLN0 reference. It also differentiates better to the checkbox used for other type of logical nodes.

I am not entirely sure what a select field is.
Perhaps another option is a checkbox which is greyed out and if any of the "children" are selected it is ticked automatically. I think that would be intuitive to the user "Oh yeah, each LDevice must have an LLN0".
I do want to do more testing but it could be done after merge because I have not found the time over the last few weeks and it all seems to work 😞

1.) Save button should be available only if a valid virtual IED can be created

Sounds good.

2.) I would replace the radio button with a select field for LLN0 type logical nodes. I think it makes it clearer for the user that there must be something - only one - LLN0 reference. It also differentiates better to the checkbox used for other type of logical nodes.

I am not entirely sure what a select field is. Perhaps another option is a checkbox which is greyed out and if any of the "children" are selected it is ticked automatically. I think that would be intuitive to the user "Oh yeah, each LDevice must have an LLN0".
I do want to do more testing but it could be done after merge because I have not found the time over the last few weeks and it all seems to work 😞

1.) Save button should be available only if a valid virtual IED can be created

Sounds good.

2.) I would replace the radio button with a select field for LLN0 type logical nodes. I think it makes it clearer for the user that there must be something - only one - LLN0 reference. It also differentiates better to the checkbox used for other type of logical nodes.

I am not entirely sure what a select field is. Perhaps another option is a checkbox which is greyed out and if any of the "children" are selected it is ticked automatically. I think that would be intuitive to the user "Oh yeah, each LDevice must have an LLN0".
I do want to do more testing but it could be done after merge because I have not found the time over the last few weeks and it all seems to work 😞

A select field is a drop-down element that only shows you the selected element, but hides the other potential options. See for example mwx-select or our wizard-select. We need something selectable in this function, as there might be more than on LNodeType of class LLN0 in the DataTypeTemplates section. In case the LLN0 is already predefined in the function, we disable the select field to indicate that this is the only option.

I have decided to remove the use of wizard-dialog and use the mwc-dialog instead. I don't think this wizard is really general enough to be part of the wizard-library in open-scd-core.


[PORT] Update Prompt.cs

Port this change from botbuilder-dotnet/master branch:
https://github.com/microsoft/botbuilder-dotnet/pull/3296

AppendChoices comment summary mentions it can be overriden, hence marking the method as virtual.
Changed projects

Microsoft.Bot.Builder.Dialogs

Closing.  Methods in Python are dynamic and don't require modifiers.


PR: JS3 syntax errors and typos

Closes #2200 #2201 #2209 #2212 #2217

Thank you, brother!
On Wed, Aug 24, 2022 at 4:33 PM Flacial @.***> wrote:

@.**** approved this pull request.
Looks good 🌟
—
Reply to this email directly, view it on GitHub
https://github.com/garageScript/c0d3-app/pull/2218#pullrequestreview-1084618949,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOWHKOM4WXAX6FFDMT3USGTV22WL7ANCNFSM57RC7YSQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

Here are the UI that should reflect the changes

@Sly, For some reason when an array is passed into a prototype function
this way, it has to have a semi-colon for some reason. Otherwise, it throws
an error in output.
There was another issue & PR that addressed a similar issue. (PR #2205)
https://github.com/garageScript/c0d3-app/pull/2205
On Wed, Aug 24, 2022 at 4:45 PM Sly @.***> wrote:

@.**** commented on this pull request.
In content/lessons/js3/sublesson/objects.mdx
https://github.com/garageScript/c0d3-app/pull/2218#discussion_r954384863
:

@@ -1936,11 +1936,10 @@ object {}, to store the results.
common element.

-;[9, 8, 7, 8, 7, 7, 7].getMostCommon()[
+;[9, 8, 7, 8, 7, 7, 7].getMostCommon()
  // returns 7 because it is the most common element

Why is there a semicolon at the start of these two lines?

—
Reply to this email directly, view it on GitHub
<https://github.com/garageScript/c0d3-app/pull/2218#pullrequestreview-1084625010>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOWHKOLJRK2R6NWQK7G67SDV22X2PANCNFSM57RC7YSQ>
.
You are receiving this because you were mentioned.Message ID:
<EMAIL_ADDRESS>


Wrong formula in the description of PrepareEntangledState operation

The formula that follows "prepares the maximally entangled state" is incorrect

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 82b3d14d-02db-e961-c376-d6977f1f2516
Version Independent ID: ffb261c5-5ed8-f68f-d9a7-5bd01a58807d
Content: PrepareEntangledState operation (Microsoft.Quantum.Preparation)
Content Source: api/qsharp/microsoft.quantum.preparation.prepareentangledstate.yml
GitHub Login: @anpaz-msft

I fixed the sources for the formula as part of https://github.com/microsoft/QuantumLibraries/pull/111 - once we update apidocs for 0.7 release the issue will be resolved. Thank you for pointing this out!